hi all,
thanks very very much on the advice
it is very useful
~manchi
On Apr 5, 2006, at 6:17 PM, Brian Topping wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
