Hi,
If I understand correctly, the problem is that a 'staged' release still
contains a SNAPSHOT keyword in the metadata/filename?
Also, how would you see snapshot 'releases' without a snapshot keyword?
If there's no indicator (timestamp?) in the filename, you'll overwrite the
previous deployed versions, which is bad.
Personally I'm pro release-candidate marking of artifacts. Either you
have a '1.0-<timestamp>' release candidate version/file, or '1.0-rc1'.
Doesn't really matter except that -rcX is more human readable. All
snapshot deployments of artifacts could then be seen as release
candidates/staged
artifacts.
What if maven understood the difference between the version in the pom
and the version in the filename? You could deploy a release candidate
with -rc1 (or timestamp) in the filename. This file will never change.
The POM itself mentions the version without the -rc1.
Then all you have to do when promoting a staged release to a real release is
move the files to another directory (one without -SNAPSHOT or -rcX in the name),
and rename the files in the process. No file contents have to be changed.
You can never get access to that release candidate unless
you specify '-rc1' in the version tag of dependencies on that artifact.
Example of the repo structure to clarify things:
groupId/
foo/
1.0-rc1/
foo-1.0-rc1.jar
foo-1.0-rc1.pom (<version> tag here says '1.0')
1.0/
...
bar/
1.0-rc1/
bar-1.0-rc1.jar
bar-1.0-rc1.pom (<version> tag here says '1.0')
1.0/
...
For projects apart from foo and bar that depend on this artifact, this works
(comparable to SNAPSHOT artifacts).
For dependencies of the rc artifact, it won't, unless you release per artifact:
Assume both foo and bar are in the same release cycle, and foo depends on bar.
The foo pom cannot be changed when released, so it's <dependency> on bar has to
specify 1.0-rc1.
This is a problem. But easily resolved:
groupId/
foo/
1.0/
maven-metadata.xml
The metadata file mentiones that 1.0 is not released yet, and lists all release
candidates. So when resolving bar-1.0 from foo, the metadata file is consulted
and the 1.0-rc1 is used.
The bad thing about this is that this works like SNAPSHOT resolution, except
instead of specifying '1.0-SNAPSHOT' and getting '1.0-<latest-timestamp>' you
specify '1.0' and get the latest '1.0-rcX'.
This is not necessarily a bad thing: if you want to promote foo, you also have
to
release bar. Maven should check if 1.0 is resolved to 1.0 or an rc before
releasing.
Also something could be done in maven internally to mark projects as non-final,
since it knows when resolving 1.0 that it got an RC.
The scheme above is almost identical to SNAPSHOT resolution. Differences:
- no SNAPSHOT tag in the artifact files themselves
- wheter something is a SNAPSHOT is determined from the absense of the artifact
in the correct version dir (1.0 is a snapshot since 1.0/ doesn't contain
foo-1.0.pom
and the metadata file points to another version).
If you look at a pom file that has no SNAPSHOT in there, you won't know for
sure if it's
a snapshot unless you check where it's resolved from.
Normally this is never a problem - all artifacts are resolved from the local
repo.
When creating wars or other compound artifacts, or assemblies, the filenames
should
match the <version> tag.
For instance, assume foo is an ear project, embedding bar.
If bar would be embedded as bar-1.0-rc1.jar, foo's contents would have to be changed on
the final release because bar's filename would change, even though the version
wouldn't.
So when looking at a file bar-1.0.jar and the embedding pom you can only tell
that it's
a snapshot using the metadata file from groupId/bar/1.0/.
Thoughts?
Dan Fabulich wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
