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 ...


28

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 ...


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 ...


21

Two options: a) Don't. Just make sure you have reproducable deterministic builds, that is, building the same source control revision with the same configuration always produces the exact same binary. b) Designate a directory somewhere as the authoritative source for published builds. Make uploading the binaries part of the deployment / shipping procedure,...


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). ...


21

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 ...


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 ...


16

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 (...


15

Option A. Just using mainline and tagging for release Pros: You avoid merge hell. Keeping to the mainline encourages some best practices like proper release planning, not introducing a lot of WIP, using branching by abstraction to deal with out-of-band long term work, and using the open closed system and configurable features for dealing with ...


14

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 ...


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

Use an artifact repository for binaries, not a version control system. A specific version of a released binary is not supposed to change over time, hence version control does not make sense since the file(s) wouldn't change. See for example Maven repositories as a repository to archive/publish/offer releases and other binaries (e.g. such as documentation)


10

As noted, svn log will get you this answer. But this really isn't suitable for time tracking -- just about all accounting systems need a hole for restatement, editing a svn commit description can be tricky if not impossible due to post-commit hooks. You might want to look at something like redmine which integrates with SVN and has a time tracking feature ...


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 ...


9

I like the idea. BitTorrent is possibly the best solution for sharing large files among numerous users devised so far, it's a shame that the stigma it carries will probably continue hampering it's mainstream adoption. Still, many open source projects, including Linux distributions, use torrents as a secondary channel of distribution You can find several ...


9

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 ...


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

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 ...


9

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 ...


8

Follow your instinct. It'd be nice if you could make the release candidate look one way before release and another way afterward, but you're right: it's important that the released version be exactly what QA approved. In my experience, the usual MO is: Produce test (alpha, beta) versions that are clearly marked. Send them to QA for testing. As you get ...


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

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 ...


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

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 ...


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. ...


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