30

Personally, I choose option 3: keep versioning information in VCS metadata, specifically, tags. Git makes it very easy to do so, because there is a command git describe, which can uniquely describe a commit based on a tag. Here's how it works: If the current commit is tagged, output the name of the tag. Otherwise, walk the history backwards until you find ...


29

You hesitate because you don't want to make semantic versioning, you want to make "advertisement supporting versioning". You expect a version number "2.0" to tell the world that you have a bunch of new cool features in your library now, not that you changed the API. That's ok (many software companies and/or developers do that). IMHO you have the following ...


27

Most places I have worked the QA people do have some sort of sign-off step, but do not have final authority on if the release proceeds or not. Their sign-off represents that they completed the testing expected by the release plan, not that the release is flawless. Ultimately QA != the business and the business needs to decide if they are OK with deploying ...


22

Semantic Versioning seems to be at conflict with most desktop application numbering. We solved this by handing over "product versioning" to the marketing department, and we maintain completely separate (but logical to us) versions for all the components. A specific product version then becomes a defined collection of compatible components. Maintaining ...


21

In my experience, it's easiest if you can have a development and release cadence that doesn't get in the way of what you want to get done. Here's how I've done it: Write the features down, and give them a rating that reflects how much you want to work on it and how much you think it will benefit the user (it may be possible to engage actual users for this). ...


18

The answer here is to communicate. Tell the technical/team lead about the issue Talk to QA about the potential impact Tell project management (who is right behind you) that there might be an issue that causes the release to be delayed, and you will get back with them ASAP (in a matter of minutes or hours) Evaluate whether this issue is a show stopper for ...


17

You should not have stabilization sprints. Your software should be releasable every sprint. This means that if you need stabilization, that has to happen within each sprint and not just before a release. Once you achieve this, release planning becomes a product owner concern ("What features to I need in order to release?") and stabilisation a team concern (...


16

I adapted semantic versioning for desktop or web applications, so in our work we are using: X.Y.Z Z is increasing if a release contains just a bug fix, dependencies update or some application internal changes, so no new functionality introduced to user; Y is increasing if a release contains minor changes in UI or just introduces some new feature, or some ...


16

How to manage release with Git and GitHub ? The Git standard way of identifying a release is to create a version tag. This tag marks a specific version of your software in the change history of your repository. Most teams work with tags, because these are directly available in the repository and can be used in git commands. The releases are a GitHub ...


14

I'll try to post some helpful hints, but with all due respect, this is Release Management 101, and if you really have a huge code base and a need for parallel work streams in the organization, you would do well to either read a book on it or hire somebody with more experience in this area. Assuming this situation: The business needs new functionality that ...


12

If I were in your shoes, I would take this as a chance to improve the build scripts so they can provide more detailed information about what exactly is failing, so finding the root cause should be a much simpler process than it seems to be now. Moreover, instead of "simulating their operating environment", why don't you just walk over to the place of the ...


11

Assuming that the new features are backward compatible, you should increment the MINOR version number, an reset the PATCH level, . Rationale: semver 2.0.0 makes this crystal clear in clause 7: Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if ...


10

As you can't control when the mobile apps will be updated to a new release, you need to version at least your REST API. If you don't it will be impossible to make backwards-incompatible changes to that interface. Besides the REST API, it is a good idea to version also the other communication interfaces that go over a network interface. That way, you are ...


10

The problem seems to be to me that you have a single QA branch. For each release, make a separate QA branch from the primary development trunk/master. Then merge in only fixes for bugs for features on that branch - never new features. Have QA test that branch. This way, the "freeze" is quite evident- it's in the branch name. You could use something like, I ...


10

I don't think the terms release" and "deployment mean exactly the same, thing I'm not sure they should be used interchangeably like that. From a web development perspective: Deployment refers to getting your program to a running state on a server. It doesn't need to be the production server. You can deploy an application/module to a testing server that is ...


9

You'll want to read up on the term "technical debt". If time & resources permit, it is much better to do any code clean up immediately while the problem is fresh in your mind. Leaving clean up as a to-do item for others can turn into a very bad habit. These to-do items are rarely addressed, and after many years can lead to such a horrific mess that ...


9

Yes. It is good practice to keep most of the version number in vcs. If we consider semantic versioning semver.org where we have major.minor.patch.build the first three must live in vcs. The last one can be a incrementing number from your build server used to backtrack the specific commit that a binary is made from. To facilitate this in .NET we have made a ...


9

Even if you are working continuously on a project, unless the project is tiny, you'll have to switch between features, some of which you haven't modified for months or years. And if you work in a team, chances are you will constantly discover parts of the code base you haven't written in the first place. So what makes it possible to reduce the time wasted ...


8

It probably has to be very close to be ready for general use, and already usable by some, in order to get help. That's the quid pro quo of open source. You contribute to code that is already more valuable to you than the time it would take you to start from scratch. For example, my wife used to use Microsoft Money, but we wanted to move our home computers ...


8

For new developers, you should have a document, hopefully less than one page, with complete instructions how to set up their computer to create a build that they can run and try out. (Obviously this involves getting source code, all the required tools, and so on). And the very first task of every new developers should be to take that document, follow the ...


8

Don’t just communicate the problem, document it My big concern with the other answers so far: Anything you say along these lines to the typical project manager facing an imminent deadline is likely to be ignored or forgotten. Then, you can still end up being on the hook for insufficiently communicating the risk, if something goes wrong. Let the project ...


8

The thing to remember is that merging a fix also merges all its ancestors, so if you want to keep code in 2.0 out of 1.0, your merges should always go from 1.0 to 2.0, and never the other way around. That means fixes need to be made (or rebased onto) the oldest branch possible, then merged into the second oldest, then into the third oldest, and so forth. ...


7

The answer is trite and frequently impossible: refuse to add additional features. In more depth, the answer really comes down to what makes a new feature fall into the feature creep bin? If we assume that features that creep are those that are added to a project despite the fact that their functionality is only tangential to the intended use of the project ...


7

Old post, but I was looking for a solution and stumbled upon this article of Brett Uglow (permalink) which is the best thing I have ever read about versioning applications which will be delivered directly to end-users, especially desktop applications. An excerpt from the article: ... The installer-user The installer-user is the person who has to install the ...


7

This really depends on the modules. You are saying the service require all the modules to exist - but do the modules require the service(or other modules) to exist? If you have a module that's an integral part of the project, but you have it as it's own module for organization reasons(example - models, views and controllers modules in MVC architecture), ...


7

This comment sounds right. In my opinion, as much of the build code as possible should be in the product's internal build scripts, such as ant's build.xml, maven's pom.xml, etc. This serves 3 purposes: Versions the build process along with the product. If you fork a branch of your product in source control and make a change that requires build changes (...


7

With the exception of people sunk in the real programmer syndrome, no one is going to disregard you for using Unity. Unity is a framework, like many others, that helps you make software. Saying that using 3rd frameworks and libraries is being lazy is like saying that driving(or using public transport) to work instead of walking is being lazy. While that ...


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