RE: Who should use SNAPSHOT when? RE: The Future of the Release Process.

[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.

[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