CODEWITHSUNDEEP
javalanguage-agnosticmaven-2versioning
ScArcher2
ScArcher2

Reputation: 87187

How do you version your projects and manage releases?

Our situation is as follows, but I'm curious about this problem in any situation.

We have a framework consisting of 4 projects:

We also have modules that need a version and depend on a version of beans and util.

Finally we have a customer project that consists of a specific version of the core projects and one or more modules.

Is there a standard way to version these projects?

What seems simple to me is becoming really complicated as we try to deliver releases to QA and then manage our ongoing development with the maintenance of the release (release = tag and possible branch).

I kind of prefer the following:

1.2.0 - major and minor versions + release.

1.2.1 - next release

1.2.0_01 - bug fix in 1.2.0 release (branch)

etc.

Any ideas?

Upvotes: 8

Views: 3668

Answers (9)

Ken Liu
Ken Liu

Reputation: 22914

One of the most common conventions is major.minor.bugfix, with an additional suffix indicating a build number or pre-release designation (e.g. alpha, beta, etc.).

My team numbers builds according to project milestones - a build is handed over to our QA group at the end of a development iteration (every few weeks). Interim CI builds are not numbered; because we use Maven, those builds are numbered with a SNAPSHOT suffix.

Whatever you decide, be sure to document it and make sure that everyone understands it. I also suggest you document and consistently apply the release branching policy or it can quickly get confusing for everyone. Although with only 4 projects it should be pretty easy to keep track of what's going on.

Upvotes: 1

kenny
kenny

Reputation: 22334

I use {major}.{minor}.{buildday}.{sequential}. For Windows, we use the utilities stampver.exe and UpdateVersion.exe for .NET projects that handle that mostly automatically.

Upvotes: 3

Draemon
Draemon

Reputation: 34711

I use a variation on the linux kernel version numbering system:

major.minor.bugfix

where even minor numbers indicate a somewhat stable release that may be distributed at least for testing, and odd minor numbers indicate an unstable/untested release that shouldn't be distributed beyond developers.

Upvotes: 2

Ronny Brendel
Ronny Brendel

Reputation: 4845

Currently we have no real versioning. We use the svn build number and the release date. (tag name is like release_081010_microsoft e.g.)

Older Products use major.minor.sub version numbering

Major never changed Minor changes on every release/featurerelease every 6 months. Sub is everything which doesn't affect the feature set - mostly bugfixes.

Upvotes: -1

Eric R. Rath
Eric R. Rath

Reputation: 1979

You didn't mention if any of the projects access a database, but if any do, that might be another factor to consider. We use a major.minor.bugfix.buildnumber scheme similar to others described in answers to this question, with approximately the same logic, but with the added requirement that any database schema changes require at least a minor increment. This also provides a naming scheme for your database schemas. For example, versions 1.2.3 and 1.2.4 can both run against the "1.2" database schema, but version 1.3.0 requires the "1.3" database schema.

Upvotes: 0

bhavanki
bhavanki

Reputation: 1527

We use major.minor.bugfix. A major release only happens for huge changes. A minor release is called for when there is an API change. All other releases are bugfix releases. There's definitely utility in having a build or revision number there too for troubleshooting, although if you've got really rigorous CM you might not need to include it.

Coordinating among the versions of all these projects can be done really well with help from tools like Apache Ivy or Maven. The build of one project, with its own version number, can involve the aggregation of specific versions of (the products of) other projects, and so your build files provide a strict mapping of versions from the bottom up. Save it all in [insert favorite version control tool here] and you have a nice history recorded.

Upvotes: 10

RobS
RobS

Reputation: 9422

Where possible, I prefer to have projects versioned with the same build numbering, unless they are shared. It allows for more consistency between moving parts and it's easier to identify which components constitute a product release.

As workmad3 has stated, there's really no common rule for build numbers. My advice is to use something that makes sense for your team/company.

Some places I've worked at have aligned build numbering with project milestones and iterations,
e.g: Major = Release or Milestone, Minor = Iteration, Build = Build number (from the project start or from the start of iteration), Revision = If the build has to be rebuilt (or branched).

Upvotes: 1

Steven Robbins
Steven Robbins

Reputation: 26599

In the automated build system i'm currently using I version with Major.Minor.Build.X, where Build is every time we hit system test, and X is the last Subversion revision number from the repo the code is being built from. Seems to work quite nicely for Subversion as we can easily get back to the codebase of a particular build if the need arises.

Upvotes: 2

workmad3
workmad3

Reputation: 25677

There are no standard version number systems. Common themes are to have a major, minor and build number, and occasionally a point number as well (1.2.2.1 for example, for version 1.2 point release 2 build 1). The meaning of the version numbers is highly flexible. A frequent choice is to have backwards compatibility between minor versions or point releases though.

Releases are probably best done by labeling a set of source controlled files as long as your source control allows this. Recreating a release is then as simple as syncing to the label and building, which is very useful :)

Upvotes: 2

Related Questions