Thanks for a great e-mail Joakim. I wanted to chime in with my two
cents...
(I've been off the radar for a couple of months while waiting for
permission to sign my ICLA; it's in now, and I'm now back to
paying more
careful attention to this process... forgive me if some of this has
already been covered.)
One of the goals I know we've expressed before (but not explicitly
listed here) is that Maven's release process should "lead by
example":
other projects (whether open-source or closed-source) who haven't
put as
much thought into release engineering as we have should look to us
as an
example of the "right way to do it".
IMO, the requirements around "SNAPSHOT" releases is an important
difference between open-source requirements for the release
process and
closed-source requirements... In this e-mail I want to describe an
alternative release process (overlapping with the one Joakim
described)
that never uses "SNAPSHOT" and which is more appropriate to some
organizations, perhaps especially closed-source ones.
I think we all agree that it's "bad" (at least a little bit) to
change
things at the last minute before release (whether it be source code,
binaries, or even your build process); one goal of the updated
release
process is that we should make as few last-minute changes as
possible,
and, to the greatest extent possible, "bless binaries".
But so long as you have the word "SNAPSHOT" embedded into your JARs
during development, you'll have to change *something* at the last
second, if only to remove the word "SNAPSHOT".
There is another way, which is better for at least some groups
some of
the time. If you never used "SNAPSHOT", but Maven enforced a
requirement that all JARs would have build numbers embedded in
them (not
appearing in the file name, but appearing in JAR manifest.mf and
in the
deployed POM), then the release process could be as little as copying
the JARs into the right place and updating some metadata to call them
released.
Here's another way of saying the same thing. The release process
Joakim
described goes like this:
a) Call vote
b) Wait on approval.
c) Collect release information.
c) 'prepare' release (occurs once)
d) 'stage' release (occurs 1 or more times)
e) Wait on consensus from PMC for blessed artifacts.
f) 'bless' release (occurs once)
As this is described, it sounds as if projects would normally spend
extremely little time in step D, "stage". But if Maven provided more
complete build numbering support for non-SNAPSHOT builds, you could
imagine the project spending their entire development life in step D.
After step E a decision was made to release, in step F the blessing
would occur, and development would immediately begin on 1.1 in
step D...
no period of time spent in "SNAPSHOT", so you wouldn't need to modify
your code ("prepare") right before release.
Although I've highlighted one big advantage of not marking code under
development as "SNAPSHOT", the most significant disadvantage of
doing it
this way is that end users might confuse "SNAPSHOT" releases with the
real official thing. (Perhaps especially if users just copy the
relevant jars out of the repository and then leave Maven behind.)
This
can result in unnecessary support questions from users as they
(unwittingly) complain about bugs in unreleased code, and can
complicated support diagnostics as the person providing support may
believe that the end-user has version 1.4, when they really have a
developer snapshot of 1.4, never intended for release.
With that said, I think most closed-source software development
organizations don't have anywhere near as much fear of end-users
grabbing under-development code and calling for support, since those
binaries are typically kept a secret; in that case, the advantage of
adding a "SNAPSHOT" marker may be outweighed by the disadvantage of
requiring special changes right before release.
Now that I've faxed in my ICLA, [heh] one of the goals I want to
pursue
as a Maven developer is to make the Maven release workflow support
organizations that would want to work without ever using
"SNAPSHOT": to
make that "stage" step a workable healthy period in a product's
lifecycle that software companies could spend most of their time in.
Specifically, I think that's how we'd want to maintain things at the
place where I work, and that's how most closed-source ISVs should
want
to maintain their software.
This shouldn't make it any harder to do open-source Maven
releases; the
fact that you *could* spend months or even years in step D doesn't
mean
that *we* should do so, or that we will. But I think a lot of users
will benefit from a richer "staging" period, so it's worth putting in
time and energy to make it really robust, IMO.
-Dan
_____________________________________________________________________
__
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
