27

This depends on how you plan which features go into which release. For example, if any feature that is merged during a certain timeframe will make it into the 2.4 release, then you can use that version number directly. If you do not know the next version, it would still be reasonable to update the docs immediately, precisely because it's best to keep code ...


5

These aren't really substages of beta, they're just different approaches to beta testing. I can't think of a scenario where you have both a perpetual beta and a temporary open/closed beta. Similarly, the difference between a closed beta and an open beta isn't really meaningful in the versioning - the dev process might release v1.0.0-beta.1 which the product ...


5

Is SemVer applicable? Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive. Can the database be subject to SemVer ? The DB engine is clearly software with an API. Your DBMS probably already uses SemVer (...


4

The closest we have to an accepted definition of "patch level" comes from semantic versioning (semver), where a patch level is the third component of a version number, which gets increased if a release only contains backward compatible bug fixes. However, semver is not universally used and others may use the term "patch level" in other ways.


4

It's possible by having two distinct lists of dependencies, one with ranges, and one with specific versions, known as a lockfile. Version ranges are helpful for libraries so that bug patches in your libraries' dependencies can be included without the libraries needing to be updated. They also give you the option of choosing a library version that meets the ...


4

The short answer is "when it is needed". Documentation doesn't live by universal rules, it's a matter of convention and doing what makes sense for your current context. That being said, there's a reasonable line to be drawn here that versioning and actual documentation context should generally be separated so as not to distract from each other. (...


4

Are the above assumptions correct? It sounds like you have a hidden assumption that is wrong: namely that the field has a fixed meaning and usage. The thing is: the basic concept of what a "version" or "release" is changes with the development process, and with that the meaning and usage of the field changes. In a heavyweight process ...


4

So do we need to increment the build number when the source code changes? No, you need to increment it when you build the application. Build numbers increment per build. That's why it's called a build number. Generally speaking, builds refer to compilations done by a dedicated build agent, and it does not include any local compilation a developer may do on ...


4

In a typical setup, build numbers are used when you have a central server that builds your software (often as part of a Continuous Integration pipeline). Those builds are then done periodically and/or when a change in the repository is detected. In such a setup, the build number is provided by the build server and will increase for each build that the server ...


4

The trade-off being made is highly reproducible builds over having the latest dependencies. Why would you want highly reproducible builds? There are a lot of reasons. You can't rely on the versioning of the dependency. Although Semantic Versioning has rules, there's no guarantee that the third-party dependency is following those rules. Even if they are ...


3

If you are asking what is the correct usage of version numbers under SemVer, then the answer is: changing from 1.0.0 to 2.0.0 would be the right thing to do, as you introduce breaking changes to the API of the app. If you are asking about project naming and versioning practices in general, then here is the long answer. Unless original WizardProject is so ...


3

The Fix Version field in Jira and related fields in similar tools are not only applicable to monolithic applications in a sequential or waterfall process. Having CI/CD does not make this field useless. The value is greatly reduced if there is Continuous Deployment where every commit is deployed to production - at this point, tying the commit(s) to the issue ...


3

the language considers String from "string 1.0" a different type from String from "string 1.1" Well, you found a major flow in the language you're designing. Types should be identified by their namespace. As soon as the namespace is kept unchanged between versions, a consumer would use string.String independently if the type is actually ...


3

Given this licensing model, you need to provide indefinite front-end support unless you want to force customers to upgrade their back-end (or switch to a competitor.) One option would be to support only a limited number of historic back-end APIs with the front-end app but provide legacy versions as separate apps. Users will have to install a legacy version ...


2

What does a version number represent? A release is the output generated by following a defined process using build tools on source code. So, if the release process or build tools change, even when used on the same source code, then the release should be considered a different version. It is because of this, that the version number should be managed by ...


2

Separate the versioning and make it a function of release. This means the versioning of APP from LIB as well as with respect to functionality. For both APP and LIB, version a set of cohesive changes. For example, if F1 and F2 are two sets of highly related changes, as soon as one is finished, incorporate them into LIB and have a tested LIB. If you decide to ...


2

You are right that pinning the exact version of dependencies forecloses many advantages: Getting a bug fixed without intervention. Getting a performance upgrade without intervention. Getting a feature upgrade without intervention. Having an easier time matching the dependencies versions to each other. On the other hand, programmers are only human, thus: ...


2

The problem now is I find it hard to rectify the use of version ranges with the idea of having reproducible builds. It is obviously impossible. how it is ever possible to have reproducible builds with version ranges when using npm You can't. What makes you think you can? This doesn't even have anything to do with NPM. It is just basic logic. "...


2

You can have a reproducible build and version ranges for your dependencies, so long as each build does not reinstall dependencies. The version range is a setting in a config file, but a build is more than a config file. If the code is exactly the same, including dependencies from NPM, then it is a reproducible build. The challenge is to only download those ...


1

If the business requires that you store an additional field/column of data, then there are essentially three possibilities: You modify the code to require the new field but don't touch the old data. This effectively renders the existing data inaccessible which is not likely to be accepted by the business. You write the reading code such that it can handle ...


1

As far as SemVer is concerned, it depends on the slightly philosophical question of whether your Python code is "a new version" or "a new project". If you decide that your new project should have its own brand, as PythonWizard, SemVer doesn't apply: it's a new project, and can start wherever it wants. On a strict reading, it ought to ...


1

If you want to maintain one database and support multiple API versions, then you should handle this kind of validations in API and model layer. Just before the request hits the DB. Leave the schema untouched and flexible as much as possible. Else, you will break the API for existing customers and you will be forced to migrate them (which no customer likes). ...


1

There are really two questions here: How can I use Semantic Versioning for an open beta? How can I use Semantic Versioning for a perpetual beta? They each have their own answers. To use SemVer for an open or closed beta, you would use it exactly as it's described in the question. The main segment of the version would reflect the target version that the ...


1

A simple solution to this is packaging major versions as a single compatible product (at least for the core functionality), with minor versions implementing additional non-core features, which may or may not work in all frontend-backend combinations. For this, you'll want your semantic versioning on the API between the frontend and backend. Update major ...


1

The most useful technique for designing an API that allows long term evolution is following REST constraints. The REST constraints your API design to techniques that will allow you to evolve your API, while maintaining long term evolution. Some of the higher REST maturity principles that are often overlooked, like uniform resources identifier, HATEOAS, and ...


1

You need to have as a simple versioning schema as you can. It leads to high maintenance and pain to have it to complex. The primary reason for having version numbers is to signal expectations about a new release. Like if the major version didn't change, expect the new release to be backward compatible. But that is only necessary if you have clients consuming ...


1

In my experience there is a distinct difference between "internal revision/tag identifiers" and "public release/version numbers."


1

You need to better understand the specific requirements you have from versioning. Most of my cases are end user applications. In this scenario a single version number is sufficient, all I require from the version is to match it to a commit ID. Other, less frequent, cases are libraries. In this case there is an additional requirement to match to an API ...


Only top voted, non community-wiki answers of a minimum length are eligible