Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a pattern for versioning my program:
major.minor.patch
Major is a complete new version of the program which is seldom increased. Minor is for new features and patch for bug fixes.
The question is, if in a new update of my program I have a new feature and I have also fixed a few bugs, should patch and minor both be incremented or does an increase of minor would suffice while patch remains zero?
As #purplehuman pointed it out, it is rather a personal decision and has no big consequence.
The convention I guess would be to increment the minor (to 1.1.x), and set the patch level to 0 because a patch level is usually relative to a version (major.minor). I would add that it may be odd to some people to switch from 1.0.0 to 1.1.1 without going through the 1.1.0.
But it is not that important, IMHO. Usually bug fixes may come in any major or minor new release, so the users would probably go check the changelog to see if/what bug fixes have be made. So don't spend too much time on this. ;-)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I wrote a program in the C language. Now I want to make the system documentation for that program. And, I would like to state the minimum system requirements that are needed to run my my program.
How do I find out what they are?
Things you can do:
Try running your app on the oldest machines you can find.
Remove a couple memory sticks from your computer
Do you have a define _WIN32_WINNT in your application? If not, the windows SDK you use will define the minimum OS requirement.
You can also try compiling with -D_WIN32_WINNT=xx for an older version to see how far back you can go, based on the Windows API calls you use. windows.h is pretty good at hiding APIs for versions newer than the one you specify with _WIN32_WINNT. Then keep that setting to compile your app to create test and release binaries.
Here's the MS doc on versioning with _WIN32_WINNT: https://msdn.microsoft.com/library/windows/desktop/aa383745
Silly me! I forgot to add that you MUST test on the oldest version you specify in your specs + the one most used by your target users.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
As the title said,
I was considering using React in a production-ready project (in particular: Meteor's Material-ui module).
As it's not even at v1.0 then is it stable enough to use in production? What downsides are there to using a <1.0 version?
If you or the organisation you work for are a devoted follower of the semver method of versioning then it would be very risky to use anything that is less than v1.0 due to the following clause:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
All this means is that that a library changing from 0.x to 0.y (including 0.x to 1) may have a completely different api which could mean you need to do a lot of work to upgrade.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am looking to create an application for exchange rate of foreign currencies and need backend for the same. While searching for the same, i came across:
http://rate-exchange.appspot.com
http://rate-exchange.appspot.com/currency?from=USD&to=EUR&q=1 //working demo
I also find the github source for this GAE project at:
https://github.com/hippasus/ExchangeRates
Now the question I have how should I proceed. Shall I use this already deployed project named http://rate-exchange.appspot.com or deploy my own version. If I should deploy my own version then what will be steps.
Thanks in advance
Generally try to use existing code with permission and visibly give credit to avoid plagiarism. Developers who repeat work already done by others learn from the experience but risk wasting time unnecessarily. You learn from others by studying their code anyway.
You may after some experience with the other project think of ways to improve it. Liaise on Github with the original author about constructive collaboration. Sharing code is what makes free and open source software great.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What determines what version number a program or release should be?
For an example: Version 2012.1.0.125
Or: 1.0.269
and so on.
What determines what the Version Number is?
First, this varies from project to project. These are just my observations:
Some projects use dates: e.g., 2011.11.12.1 for the first release on November 12th, 2011. Most projects will have some boneheaded mistake that necessitates a near-immediate re-release of a new, fixed version, so the .1 at the end will eventually be called into being, if it wasn't there from the start.
Some projects use major.minor.subminor version numbers; typically, the subminor number will incremented for bugfixes. When enough bugfixes have been collected, or a new feature that's really neat has been introduced, then the minor number is usually incremented. Bumping the major number is often reserved for releases that break API compatibility. (Sometimes releases that break ABI compatibility are done with minor version updates, but hopefully those are rare and not common.)
Some projects use a CVS or SVN checkin identity, or some "build number" to represent builds, as part of the version numbers. These typically include larger numbers such as your 125 or 269. These numbers are chosen because they are nicely monotonic, but don't carry much meaning themselves.
Typical industry convention is Major.Minor.Build with a transition from 0.x to 1.x indicating Beta to Production. Let me repeat, it's a convention and not a law of man or nature or a marketing department.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am writing a dissertation for university final year.
I want to put a large amount of source code on a DVD for the appendix.
95% of code is written by me, but some code is copy and pasted from samples and taken from forums.
Do I have to label each bit of code that is not mine or something?
What would I write if I don't know who's code it is anymore?
You should definitely cite your source if the source specified you do so. However, if you are taking samples and adapting them to your environment you usually don't have to cite it (as long as it has changed in a significant way).
Usually, I try to include a comment in my code if I just copy and paste something, even if it is free and open to copy. However, this is more of a preference than a specification.
In the end, it is up to the people you got the code from (if they specified a license for the code) and your advisor at the university.