Tag Info

New answers tagged

3

I think some of the challenge starts with your assertion of: Where a Major version is implemented whenever there are breaking changes And I'm pretty sure you mean "breaking changes" in the sense of significant API changes; client / server communication changes; protocol work, etc. "Big Stuff" (TM) in other words. But the problem is that it's not ...


1

Whatever you're using internally, externally you're still going to have a waterfall like release cycle. Whether it's now called a "feature release", "release to production", "customer delivery version", or whatever, it's going to be the combined product of a number of sprints and shorter internal cycles. That's where the high level numbers come in. So ...


3

If the user of your software is not able to update to the new version and use it without further manual migration steps (data, configuration, interfaces and the like), that is a strong indicator to increase the major version.


6

Alice should handle this situation by rejecting the pull requests which also change the version number (both of them). Collaborators who are not the maintainer should not be changing the version number - that is the job of the project maintainer.


5

If Alice is the maintainer of the project, then Alice and Alice alone should be the one that increments the version. Increasing the version number means a release, and Alice is the one to decide when to release - not Bob and Carol. Whatever code Bob and Carol contribute, you can be 99.99% certain it'll still work even if they don't increment the version ...


1

As far as I understand you, there is no maintenance for those older versions to do - only for the newest version (changing of older version is forbidden, right?). That means, even if the function names become very technical after versioning, this should not be too much of a problem, since you never have to touch that code again. You need to store the ...


1

Not as such; There is not one standard versioning scheme. As such, each project tends to choose a versioning scheme that fits their development/release model (and this is perfectly fine, as long as the versioning scheme is known, consistent and respected by developers). Here are some version examples I've used over the years: Linux/OSS - style version ...


2

It appears to be fairly common, yes. Have a look at the Wikipedia article on software versioning. Quote below is from that page: Designating development stage Some schemes use a zero in the first sequence to designate alpha or beta status for releases that are not stable enough for general or practical deployment and are intended for testing or ...


0

The whole confusion stems from the different semantics that MS uses for "Build number" and especially "Revision". The terms just mean different things. Most people (myself included) use a semantic version numbering scheme where you just get a higher BUILD number whenever you have to make a new build for whatever reason. For us, a hotfix is considered just ...


1

Let me just say how I see and use it.... ProgramName version major.minor.build.revision major: For me is the current project I am working on. The number will not change until I start a new project of the same program name. This means I will literally be writing a new program of the same gender (example: access v1 - access v-2 - access v-3 * all the same ...



Top 50 recent answers are included