New answers tagged

1

Every release to customers should have a new version number. Every release to testers should have a new build number. Customers will think something is wrong if version numbers are missing, so a sequence of version numbers could be for example 1.3.0, 1.3.1, 1.3.2, 1.4.0 etc.


2

Looks like a potentially large change. It depends on the language/platform, but if you're using Java and you've added a checked exception, then your clients may not even be able to compile their code against your library without changes. Regardless of compilation issues, your library has a potential change in behaviour affecting the using code, and your ...


2

Not really, if the source code is obtained from the tagged branch, then its obvious which version is which! You may have more difficulty if you're working on a branch, which is probably taken from trunk, or one taken from a tag so you won't necessarily know which version the source corresponds to. If you can find the version the source came from, then its ...


3

Semantic versioning is quiet on roadmaps: it only cares about the actual release tagged. In your case, if feature 3 is completed ahead of schedule, it's up to you to decide whether it'll make it into 1.1.0 or if it should remain in 1.2.0. To have that type of flexibility though, you'll want to carefully consider your integration/release process. If you're ...


9

First of all, SemVer.org is all about version numbering for libraries and APIs. You can borrow the ideas to use for applications, but note that it's not a perfect fit (for example, SemVer says the MAJOR version number increments when you make a non-backwards compatible API change) You don't work on "FEATURE 2" or "FEATURE 3", you work on "FEATURE ...


1

Retrofit library is a great example for this. It's not been that long since they introduced a stable version 2 which is really good even if it did bring some breakages. Some of the notable things that they did were: The new API has a lot of value and addresses much of the shortcomings of the older version. This means that your new API must be very good. ...


3

This approach is rather common. It allows a smooth transition to a new API, and a safe evolution towards new implementations. Of course, the if/then approach, as highlighted by Laiv in his answer, has some drawbacks. It's tedious. It's easy to forget or to mixup things. Ideally, the use of wrappers, factories or adapters could provide some nicer ...


0

I don't think that spliting code with if/else is a good approach. Think a long time term. What are you going to do with further versions?. ) How user code can end up being along the time? For minor versions or reviews, to keep compatibility is expected. @Deprecated comes with comment asking for to developer to don't use that code. It also suggest what ...



Top 50 recent answers are included