I would echo Eric's sentiments, with a caveat.
A lot of smaller (in house, no exposed APIs) projects can be helped
by starting with build numbers taken directly from the subversion
revision ID. This is a monotonically increasing integer, and by
using that for your release ID, there's little or no reason to use
tags, since every release ID _is_ a tag. The use of the release ID
also gives users a very weak idea of how much difference there is
between two builds.
What release IDs do not do is provide information about architectural
changes. For instance in the traditional number of x.y.z, a change
in x would indicate a substantial or full rewrite of the product, a
change in y would indicate potential incompatibilities, and a change
in z would indicate bug fixes. But if you are running a small shop
that does not have customers relying on the APIs of your product, you
can just use subversion IDs and save yourself a ton of time, since
architectural changes don't matter to anyone but the engineers, and
all they care about is where to find that version in the source
repository.
As Eric said, you can always add later, but it's hard to take away.
So start with SVN IDs, and if that's not enough, move on to simple
version numbers (as tags) as an external communication aid.
HTH,
:b
On Apr 4, 2006, at 8:06 PM, Eric Redmond wrote:
Well, sorry to dissapoint, but I'm not an expert... I am, however,
full of
opinions!
This is how I tend to number, and it works well for me:
Skip bugfix numbering unless you are working on a major project.
Seriously.
It gets very burdonsome to handle multiple minor edits on smaller
projects,
since they either 1) change a lot... meaning that all of their
dependencies
are expected to change? Naw, just use SNAPSHOTs or timestamps. 2)
rarely
change... meaning, why would you need to keep track of version
1.0.1 versus
1.0.2?
Now, that said, bugfix numbering is good for larger projects, like
linux,
jboss, or maven. The difference between 2.0.0 and 2.0.3 is fairly
substantial. So, what's the difference between a small and large
project?
Well, thats up to you. Just don't get overzealous. Remember: you
can always
add decimals later, but its hard to take them away (try and explain
to your
users and developers why you moved from 1.1.0.1a to the number 2:
"what
version is this, really"?).
Parent and aggregator projects (pom packages) can live quite well
with a
single number. 1, 2, 3... no need to complicate matters, they don't
change
enough to need minor numbers, and when they do, its a pretty major
change
for their children.
Addendum to the previous statment: if the artifact is the top
aggregator of
a large project. Since this version will tend to be the project's
actual
version, use the actual project's numbering scheme.
I also like to use the *-alpha-1, *-beta-3, *-RC-1 style of naming. It
works, its descriptive, and it lets users know if they're using a beta
project right off the bat.
I'd love the chat more, but the new episode of "House" is on!
Hope this helps;
Eric
On 4/4/06, Man-Chi Leung <[EMAIL PROTECTED]> wrote:
hi,
sorry that it is not a direct question on Maven usage, but I really
hope to improve my Release management process with Maven.
I would like to understand more regarding version numbering
convention, perhaps, the most commonly practice in Java community.
1) for subversion source tree. it is using Release.Minor.Bugfix-
ReleaseCandidate scheme
e.g. from 1.0.x -> 1.1.x ->1.2.x -> 1.3.x
1.3.x-rc1 -> 1.3.x-rc2 -> 1.3.x-rc3
2) in linux kernel, 1.x , odd-numbered releases (2.5, 2.7, etc.) are
unstable development versions, while even-numbered releases (2.6,
2.8, etc.) are stable consumer releases.
3) Eclipse community is using a term "Milestone". it is from 2.x M1 -
2.xM2 ... -> 2.xM6 -> 3.x , etc
4) Apple is practicing number-letter-number scheme, also having
development version & marketing version
e.g first build of Panther (10.3) was 7A1. The first public release
was 7B85; the last, 10.3.9, was 7W98. But the next build of OS X was
10.4, 8A1
5) in general, there is also 1.x apha , 1.x beta , 1.x final release.
etc
6) in Maven and relating maven plugin, there is a SNAPSHOT scheme.
i would like to find out more about the differences and good
practice. any expert can help?
thanks so much for help and advice!
Regards,
manchi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
