You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Dan Fabulich <df...@bea.com> on 2006/12/14 04:11:15 UTC
Who should use SNAPSHOT when? RE: The Future of the Release Process.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Tom Huybrechts <to...@gmail.com>.
On 1/2/07, Dan Fabulich <df...@bea.com> wrote:
>
> Wendy Smoak wrote:
> > On 12/22/06, Dan Fabulich <df...@bea.com> wrote:
> >
> > > > From: Kenney Westerhof [mailto:kenney@apache.org]
> > > >
> > > > If I understand correctly, the problem is that a 'staged' release
> > > > still contains a SNAPSHOT keyword in the metadata/filename?
> > >
> > > Yes, that's the problem.
> >
> > I would agree, but that's not how I understand staging to work at all.
> >
> > The Apache projects I work on like to vote on the *exact* artifacts
> > that will be released to the public, so the staged release must not
> > have a -SNAPSHOT qualifier.
>
> I realize now that I agreed with Kenney too soon. The problem is,
> really, the existence of a -SNAPSHOT qualifier at all, which, in turn,
> forces us to jump through hoops at the last second in the release
> process in order to remove that qualifier. (-SNAPSHOT has some
> advantages, but for many organizations, the disadvantages are
> considerably more significant.)
>
> The real point here is that the "staging" process (which creates
> non-SNAPSHOT binaries that have not yet been released) should be
> something that we could use throughout the development cycle, not some
> special last-minute thing that provides special last-minute binaries.
> The way to do that is to provide build numbers on non-SNAPSHOT releases,
> allowing us to bless a release binary without modifying it (for example,
> by moving it from one repository to another).
>
That's essentially what Eclipse does... While developing to a 3.3
release, each bundle in every build gets a version qualifier (e.g.
3.3.0.v20061116) which is incremented if the bundle changes.
The eventual 3.3 release will then just be a collection of bundles
with the latest qualifier for each.
As an example, these are some off the bundles in the 3.2.1 release.
Note that some bundles that never changed still have the 3.2.0.v....
version.
org.eclipse.core.boot_3.1.100.v20060603.jar
org.eclipse.core.commands_3.2.0.I20060605-1400.jar
org.eclipse.core.contenttype_3.2.0.v20060603.jar
org.eclipse.core.expressions_3.2.1.r321_v20060721.jar
org.eclipse.core.filebuffers_3.2.1.r321_v20060721.jar
org.eclipse.core.filesystem.win32.x86_1.0.0.v20060603.jar
org.eclipse.core.filesystem_1.0.0.v20060603.jar
org.eclipse.core.jobs_3.2.0.v20060603.jar
org.eclipse.core.resources.compatibility_3.2.0.v20060603.jar
org.eclipse.core.resources.win32_3.2.0.v20060603.jar
org.eclipse.core.resources_3.2.1.R32x_v20060914.jar
org.eclipse.core.runtime.compatibility.auth_3.2.0.v20060601.jar
org.eclipse.core.runtime.compatibility.registry_3.2.1.R32x_v20060907
org.eclipse.core.runtime.compatibility_3.1.100.v20060603.jar
org.eclipse.core.runtime_3.2.0.v20060603.jar
org.eclipse.core.variables_3.1.100.v20060605.jar
More info at http://wiki.eclipse.org/index.php/Version_Numbering
Tom
> -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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Dec 06, at 9:45 PM 22 Dec 06, Wendy Smoak wrote:
> On 12/22/06, Dan Fabulich <df...@bea.com> wrote:
>
>> > From: Kenney Westerhof [mailto:kenney@apache.org]
>> >
>> > If I understand correctly, the problem is that a 'staged' release
>> > still contains a SNAPSHOT keyword in the metadata/filename?
>>
>> Yes, that's the problem.
>
> I would agree, but that's not how I understand staging to work at all.
>
The staging directory would container artifacts as they would be
released in the wild. No SNAPSHOTs, and in the form they would be
merged into the central repository.
Jason.
> The Apache projects I work on like to vote on the *exact* artifacts
> that will be released to the public, so the staged release must not
> have a -SNAPSHOT qualifier.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Tom Huybrechts <to...@gmail.com>.
On 12/23/06, Craig McClanahan <cr...@apache.org> wrote:
> On 12/22/06, Wendy Smoak <ws...@gmail.com> wrote:
> >
> > On 12/22/06, Dan Fabulich <df...@bea.com> wrote:
> >
> > > > From: Kenney Westerhof [mailto:kenney@apache.org]
> > > >
> > > > If I understand correctly, the problem is that a 'staged' release
> > > > still contains a SNAPSHOT keyword in the metadata/filename?
> > >
> > > Yes, that's the problem.
> >
> > I would agree, but that's not how I understand staging to work at all.
> >
> > The Apache projects I work on like to vote on the *exact* artifacts
> > that will be released to the public, so the staged release must not
> > have a -SNAPSHOT qualifier.
>
>
> Agreed. When I vote on a release, I'm always saying "show me the bits."
>
> In this scenario, it would be nice for the release plugin to have an option
> to copy approved artifacts from the staging area to the release area (along
> with corresponding signatures and metadata updates) *without* any
> modification to the artifacts themselves.
>
I wrote the repositorytools plugin in mojo-sandbox for this reason. It
has goals to copy a specific artifact (including signatures) or an
entire remote repository to another repository, while merging the
necessary repository metadata.
This is still work-in-progress although Jason already tested it (I
think it was on a Geronimo release ).
Tom
> --
> > Wendy
>
>
> Craig
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Dec 06, at 10:03 PM 22 Dec 06, Craig McClanahan wrote:
> On 12/22/06, Wendy Smoak <ws...@gmail.com> wrote:
>>
>> On 12/22/06, Dan Fabulich <df...@bea.com> wrote:
>>
>> > > From: Kenney Westerhof [mailto:kenney@apache.org]
>> > >
>> > > If I understand correctly, the problem is that a 'staged' release
>> > > still contains a SNAPSHOT keyword in the metadata/filename?
>> >
>> > Yes, that's the problem.
>>
>> I would agree, but that's not how I understand staging to work at
>> all.
>>
>> The Apache projects I work on like to vote on the *exact* artifacts
>> that will be released to the public, so the staged release must not
>> have a -SNAPSHOT qualifier.
>
>
> Agreed. When I vote on a release, I'm always saying "show me the
> bits."
>
> In this scenario, it would be nice for the release plugin to have
> an option
> to copy approved artifacts from the staging area to the release
> area (along
> with corresponding signatures and metadata updates) *without* any
> modification to the artifacts themselves.
>
Yes, that's what we have just tried with a Geronimo release where the
actual release was staged, Geronimo folks votes and then I merged the
artifacts into the central syncing directory on Apache using Tom's
new repository copier which takes into account merging the necessary
metadata.
Jason.
> --
>> Wendy
>
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Craig McClanahan <cr...@apache.org>.
On 12/22/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 12/22/06, Dan Fabulich <df...@bea.com> wrote:
>
> > > From: Kenney Westerhof [mailto:kenney@apache.org]
> > >
> > > If I understand correctly, the problem is that a 'staged' release
> > > still contains a SNAPSHOT keyword in the metadata/filename?
> >
> > Yes, that's the problem.
>
> I would agree, but that's not how I understand staging to work at all.
>
> The Apache projects I work on like to vote on the *exact* artifacts
> that will be released to the public, so the staged release must not
> have a -SNAPSHOT qualifier.
Agreed. When I vote on a release, I'm always saying "show me the bits."
In this scenario, it would be nice for the release plugin to have an option
to copy approved artifacts from the staging area to the release area (along
with corresponding signatures and metadata updates) *without* any
modification to the artifacts themselves.
--
> Wendy
Craig
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Dan Fabulich <df...@bea.com>.
Wendy Smoak wrote:
> On 12/22/06, Dan Fabulich <df...@bea.com> wrote:
>
> > > From: Kenney Westerhof [mailto:kenney@apache.org]
> > >
> > > If I understand correctly, the problem is that a 'staged' release
> > > still contains a SNAPSHOT keyword in the metadata/filename?
> >
> > Yes, that's the problem.
>
> I would agree, but that's not how I understand staging to work at all.
>
> The Apache projects I work on like to vote on the *exact* artifacts
> that will be released to the public, so the staged release must not
> have a -SNAPSHOT qualifier.
I realize now that I agreed with Kenney too soon. The problem is,
really, the existence of a -SNAPSHOT qualifier at all, which, in turn,
forces us to jump through hoops at the last second in the release
process in order to remove that qualifier. (-SNAPSHOT has some
advantages, but for many organizations, the disadvantages are
considerably more significant.)
The real point here is that the "staging" process (which creates
non-SNAPSHOT binaries that have not yet been released) should be
something that we could use throughout the development cycle, not some
special last-minute thing that provides special last-minute binaries.
The way to do that is to provide build numbers on non-SNAPSHOT releases,
allowing us to bless a release binary without modifying it (for example,
by moving it from one repository to another).
-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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/22/06, Dan Fabulich <df...@bea.com> wrote:
> > From: Kenney Westerhof [mailto:kenney@apache.org]
> >
> > If I understand correctly, the problem is that a 'staged' release
> > still contains a SNAPSHOT keyword in the metadata/filename?
>
> Yes, that's the problem.
I would agree, but that's not how I understand staging to work at all.
The Apache projects I work on like to vote on the *exact* artifacts
that will be released to the public, so the staged release must not
have a -SNAPSHOT qualifier.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Dan Fabulich <df...@bea.com>.
OK, I've finally written up the Compass way of doing things. I've got
it as a blog article for easier reading (and HTML formatting), but I'm
also including the text below.
http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.ht
ml
In this article, I'll describe some of the differences between Maven 2.x
and the "Compass" internal home-grown system we use at work. I'll first
describe our repository layout, then describe our component descriptor
file, and finally I'll summarize some of the advantages and
disadvantages of using the different systems and suggest future work.
The Compass system was designed with Maven 1.x in mind. The original
developers had said, roughly: "You know, Maven's got the right idea, but
this really hasn't been implemented the way we'd want it. We should
rewrite it ourselves from scratch."
REPOSITORY LAYOUT
Like Maven, Compass has one or more remote repositories containing
official built artifacts, (or "components", as we call them,) as well as
a local repo on each developer's machine which caches artifacts from the
remote repo and contains locally built artifacts. Where Maven and
Compass substantially diverge is in how artifacts are stored in the
repository.
While Compass doesn't have a notion of "groupId", our remote repository
is divided up into sections, like this:
thirdparty/
log4j/
junit/
firstparty/
RECENT/
foo/
bar/
INTERNAL/
foo/
bar/
RELEASE/
foo/
bar/
[NOTE: This isn't exactly how it looks, but it's close enough.]
Within a given section, you find a flat list of components. In this
example, "foo" and "bar" are buildable components that we've created;
log4j and junit are, naturally, components built by other people.
"RECENT" contains only freshly built components. "INTERNAL" contains
components that have been blessed by some human being, and are intended
for internal consumption. "RELEASE" contains released components and
products.
In practice, there are 914 components in RECENT and 671 components in
INTERNAL.
Within a given component directory, you'll find a number of
subdirectories, which define the "version" of the component. Thirdparty
versions may have any arbitrary strings for their names (e.g. "3.8.1"
"1.0beta3" "deerpark"). However, firstparty versions are strictly
defined: they are simply the P4 Changelist number of the product at the
time it was built.
(A quick note about changelist numbers as opposed to revision numbers.
Most people are familiar with the distinction between CVS revision
numbers and SVN revision numbers: CVS revision numbers are "per file"
whereas SVN revision numbers are global to the repository. P4
changelist numbers are like SVN revision numbers. [Also note that you
can calculate something like an SVN revision number in CVS, simply by
noting the timestamp of the most recent check-in.])
So, within the "foo" directory in RECENT, you'll see this:
foo/
123456/
foo.jar
123457/
foo.jar
123458/
foo.jar
@LATEST -> 123458
That's three numbered directories with a "LATEST" symlink, pointing to
the most recent build in that directory.
The first thing to note about this system is that if you build 123458
and then rebuild 123458, it will replace the old "123458" directory.
The second thing to note is that if you change foo at all, it will get a
new changelist/revision number, and so it will get a new subdirectory
under "foo" once automatically built.
The three sections within the "firstparty" directory (RECENT, INTERNAL,
RELEASE) are called "release levels", and we have a process about how
components move into each release level. "foo" and "bar" are
automatically built every night and deployed into RECENT; if there are
more than three builds in RECENT, we automatically delete the oldest
build.
If somebody thinks that a build of "foo" is good enough to keep around,
they "promote" that build into INTERNAL by simply copying the numbered
changelist directory into INTERNAL. Once we think it's good enough to
release, we can promote that INTERNAL build into RELEASE by copying it
there. There is no tool, nor any need for a tool, to rebuild for
release or make even the slightest changes to the released binaries.
Especially note that we don't put any of this information in the
filename of the jar. It's called "foo.jar" whether it's in RECENT,
INTERNAL, or RELEASE. We do burn the changelist number of foo.jar into
its META-INF/manifest.mf at build-time... that information remains
constant whether "foo.jar" is copied to INTERNAL or RELEASE.
COMPONENT DESCRIPTOR FILE
Compass has a file that looks a lot like the Maven POM XML file... our
file is called "component.xml". component.xml defines a list of
<dependency> elements. Here's an example component.xml file:
<component>
<name>foo</name>
<release>6.1.0</release>
<branch>main</branch>
<depends>
<dependency type='internal'>
<name>bar</name>
<branch>2.1.x</branch>
<version>242483</version>
<release-level>RECENT</release-level>
</dependency>
<!-- ... -->
</depends>
</component>
Note that the component does not declare its own version number. (Since
in Compass-lingo, version numbers are SCM revision numbers, it would be
impossible to declare this in the descriptor file; as soon as you
checked in, it would be wrong!) Instead, it allows you to declare a
"branch" name, usually something like "main" or "feature" or "2.1.x" as
you see above, as well as a "release", which looks more like a Maven
version number, but is purely descriptive... it's not used for resolving
artifacts at all.
Also note the presence of the <release-level> tag in the <dependency>
element, which specifies the release level (RECENT, INTERNAL, RELEASE)
of the dependency in question.
We do have a simple tool that automatically verifies whether a component
is suitable for promotion to INTERNAL or RELEASE, which we call
"DepWalker" (Dependency Walker). You can use it to check to see if
"foo" depends on any components in RECENT, or whether anything "foo"
depends on (or anything they depend on, etc.) depends on components in
RECENT. Components in RECENT are temporary, and therefore unsuitable
for long-term reproducibility.
Of course, if you like, you can also wire up your <dependency> tag to
depend on RECENT/bar/LATEST. In that case, you can continuously
integrate with the latest version of bar. You do that like this:
<dependency type='internal'>
<name>bar</name>
<branch>main</branch>
<version label='LATEST'>242483</version>
<release-level>RECENT</release-level>
</dependency>
The presence of the attribute "label='LATEST'" informs Compass that we
want to automatically upgrade to the current LATEST version of "bar"
that's available.
In an optional step we call "pre-build", Compass automatically modifies
the number in <version> to match the LATEST version number. If you
don't "pre-build", the existing version number will be used. The
official nightly build system always runs "pre-build", and then
automatically checks in the updated version into source control.
With that said, you don't have to use label=LATEST if you don't want to.
If you don't care about reproducibility, you can just say this:
<dependency type='internal'>
<name>bar</name>
<branch>2.1.x</branch>
<version cl='242483'>LATEST</version>
<release-level>RECENT</release-level>
</dependency>
Since the version number is LATEST, we can't reproduce this build later.
In that case, the automated build system still performs automated
check-ins to modify the "cl='242483'" attribute, but that information is
only there so humans can know what "LATEST" was at a given time, and so
we can automatically bump the version number (by checking in, we
increase the revision number).
Finally, if you really don't care about reproducibility, you say this:
<dependency type='internal'>
<name>bar</name>
<branch>2.1.x</branch>
<version>LATEST</version>
<release-level>RECENT</release-level>
</dependency>
In that case, your build is totally unreproducible, but it has the
advantage that we won't bother with automated check-ins.
ADVANTAGES/DISADVANTAGES RELATIVE TO THE CURRENT "SNAPSHOT" SYSTEM
Advantages:
* "SNAPSHOT" is a marker that indicates that a given
component/project is under development. But that means that you
necessarily have to modify the binaries in order to release them; using
today's release plug-in, you actually have to check in modified source
code before you can release, which is really troubling.
The Compass system doesn't use a "SNAPSHOT" marker, and so
promoting/releasing is simply a copy step.
* Under today's SNAPSHOT system, there's no notion of a "build
number" for a non-SNAPSHOT release. If you deploy foo-1.0 today, then
make some changes and redeploy foo-1.0, today's deploy system will
simply replace the old foo-1.0 with the newer version.
In Compass, everything always has a build number (and it's the
same as the SCM revision number).
* label=LATEST guarantees reproducibility while allowing for "soft"
version numbering. Maven only allows for unreproducible "soft" version
numbers.
Reproducibility is generally a virtue, but specifically it pays
off when "foo" depends on "bar" and "bar" introduces a change that
breaks "foo". When "foo" is a reproducible build, you can say "this
(automated) check-in 123456 broke the build of foo", see what changed in
that check-in, and immediately identify the source of the problem (a bad
new "bar"). It also allows you to roll back to an older check-in of
"foo" to fix the problem.
With unreproducible "soft" version numbers, you find yourself
automatically upgraded to the new "bar", and no reliable way to
determine this. The same code in "foo" may build successfully on
Tuesday but fail on Wednesday, with no apparent explanation as to why.
Disadvantages:
* If you don't use a SNAPSHOT marker, it's not as easy to tell
whether the file in question is an official release or not. (This may
matter a lot more to open source developers than closed source
developers. Open source developers make pre-release builds available
for public download, which creates a risk that someone may download a
pre-release binary and then ask for support. Closed source developers
typically keep pre-release binaries a secret and only make release
binaries available through official channels.)
Since typically under the Compass system even the filename doesn't
include version information, the only way to figure out the "version"
(changelist/revision#) of a given jar is to crack it open and look at
the manifest.mf file. Even that won't tell you whether the jar has been
officially released, but it should be enough information for you to
check to see if it is an official release at all.
* label=LATEST does automated check-ins... in some cases, it does a
lot of automated check-ins. These can clutter your revision logs.
CONCLUSION
I wouldn't want to suggest from this writing that anyone should cast
aside the existing "SNAPSHOT" system in favor of Compass. However, it
is a major goal of mine to make Maven's release mechanism powerful
enough that we could follow/enforce the Compass system using Maven.
Here's what I'd like to do, in no particular order:
* Allow users to optionally specify a named repo within which you
require that a given artifact can be found. (Internally, we'd probably
use this as an equivalent to our <release-level> tag, but I think this
would be generally useful just to make it simpler to diagnose problems
when a given artifact can't be found.)
* Modify Maven's deploy mechanism and repository layout to ensure
that a build number is always available in the remote repository, even
for official releases.
* Allow POMs to declare a dependency on a particular
jar/version/build number, even for official releases.
* Enhance the build-numbering mechanism to allow Continuum and other
continuous build engines to deploy using an SCM revision number as a
build number.
* Create a mechanism that will allow you, if you wish, to
automatically upgrade dependencies in POM files, by declaring both a
literal version number + build number as well as a "soft" version number
which serves only as a guideline for the automatic upgrade tool.
_______________________________________________________________________
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Dan Fabulich <df...@bea.com>.
Comments inline...
> -----Original Message-----
> From: Kenney Westerhof [mailto:kenney@apache.org]
> Sent: Thursday, December 14, 2006 5:07 AM
> To: Maven Developers List
> Subject: Re: Who should use SNAPSHOT when? RE: The Future of the
Release
> Process.
>
> Hi,
>
> If I understand correctly, the problem is that a 'staged' release
still
> contains a SNAPSHOT keyword in the metadata/filename?
Yes, that's the problem.
[Even the filename is a problem when you know the files will be
installed in the context of a larger assembly installed on end-users'
desktops. More generally, I think, most professional closed source ISVs
have it as a requirement that you can't go around renaming libraries
right before you release your software; if they don't make this a
requirement, IMO they should.]
> 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.
You keep them in separate directories.
http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.ht
ml
The most important change I suggest here is to modify the way we
"deploy" builds to include a "build number" directory in the repository
layout; every deployed artifact (even released artifact) would be in its
own build number directory, so they would never clobber each other.
The official "release vote" would be to vote on promoting a particular
build number to a release.
> Personally I'm pro release-candidate marking of artifacts.
I don't have an opinion about release-candidate marking in *general*,
but it should be at least possible to have a release process in Maven
that doesn't "mark" release candidates at all (even in the filename).
> What if maven understood the difference between the version in the pom
> and the version in the filename?
Whatever comes of this discussion, I hope it emerges that the point you
raise here is an essential part of the answer: some part of what you
might conventionally call the "version number" (whether that's a
timestamp, build number, or the release status) needs to not appear in
the POM, even (especially) for released binaries.
-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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release
Process.
Posted by Kenney Westerhof <ke...@apache.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Dan Fabulich <df...@bea.com>.
Comments inline...
Brett Porter wrote:
> Does this cover the whole topic?
>
http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documen
ts
I'd say that highlights a lot of the most important requirements; it's
probably best read together with the blog article as well.
http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.ht
ml
> I think it's all good - as long as it is all built on top of the
> stuff we already have (including what Joakim is proposing). It will
> probably require changes to many aspects of Maven (packaging,
> dependency resolution, deployment and release). It will also touch on
> Continuum and Archiva, I imagine.
>
> Is this right?
I would say so.
-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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Brett Porter <br...@apache.org>.
Does this cover the whole topic?
http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement
+Documents
I think it's all good - as long as it is all built on top of the
stuff we already have (including what Joakim is proposing). It will
probably require changes to many aspects of Maven (packaging,
dependency resolution, deployment and release). It will also touch on
Continuum and Archiva, I imagine.
Is this right?
- Brett
On 14/12/2006, at 2:46 PM, Jason van Zyl wrote:
> Hi Dan,
>
> I think what you are describing is what you do at your work place,
> and I think it might be good if you could give us a full
> description of your system for folks here to help them understand
> exactly what it is you're talking about. I probably know a little
> more about it then most here but I still don't entirely grok the
> workflow you're describing. Maybe some simple examples of how
> artifacts names would change through the workflow you're describing
> versus our current approach would be helpful. Anything that makes
> releases easier is a good thing.
>
> Thanks,
>
> Jason.
>
> On 13 Dec 06, at 10:11 PM 13 Dec 06, 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Posted by Jason van Zyl <ja...@maven.org>.
Hi Dan,
I think what you are describing is what you do at your work place,
and I think it might be good if you could give us a full description
of your system for folks here to help them understand exactly what it
is you're talking about. I probably know a little more about it then
most here but I still don't entirely grok the workflow you're
describing. Maybe some simple examples of how artifacts names would
change through the workflow you're describing versus our current
approach would be helpful. Anything that makes releases easier is a
good thing.
Thanks,
Jason.
On 13 Dec 06, at 10:11 PM 13 Dec 06, 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org