You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2008/03/21 23:41:06 UTC
[m2][PROPOSAL] Release process
Based on couple of JIRA comments, it seems there still isn't consensus
about a release process using m2 at Commons. I'll try to outline the
process.
<outline>
[A] Release prep
[B] Stage artifacts and site, to some location TBD (entire commands
below, not abridged etc.):
mvn -Prc release:prepare
mvn -Prc release:perform
mvn -Prc site-deploy
Or, if you don't care about the release plugin, after setting final
versions in [A]:
mvn -Prc deploy
mvn -Prc site-deploy
[C] Vote
[D] Go live
mvn stage:copy ...
mvn site-deploy
</outline>
Does this fit your mental model? If not, why not?
Please keep the discussion at a "vision" level. Yes, the outline is
flawed (all votes don't pass, there are loops etc.) Yes, required pom
changes are not discussed. But, once process is OK'ed, we will make
the poms do the right thing :-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by sebb <se...@gmail.com>.
On 22/03/2008, Phil Steitz <ph...@gmail.com> wrote:
> First, thanks for helping move this along, Rahul. We need to at least
> get the "releasing" docs updated.
>
>
> On Fri, Mar 21, 2008 at 3:41 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> > Based on couple of JIRA comments, it seems there still isn't consensus
> > about a release process using m2 at Commons. I'll try to outline the
> > process.
> >
> > <outline>
> >
> > [A] Release prep
> >
> > [B] Stage artifacts and site, to some location TBD (entire commands
> > below, not abridged etc.):
> >
> > mvn -Prc release:prepare
> > mvn -Prc release:perform
> > mvn -Prc site-deploy
> >
> > Or, if you don't care about the release plugin, after setting final
> > versions in [A]:
> >
> > mvn -Prc deploy
> > mvn -Prc site-deploy
> >
> > [C] Vote
> >
> > [D] Go live
> >
> > mvn stage:copy ...
> > mvn site-deploy
> >
> > </outline>
> >
> > Does this fit your mental model? If not, why not?
> >
> > Please keep the discussion at a "vision" level. Yes, the outline is
> > flawed (all votes don't pass, there are loops etc.) Yes, required pom
> > changes are not discussed. But, once process is OK'ed, we will make
> > the poms do the right thing :-)
>
>
> Keeping things at the "vision" level, what I like to do is
>
> 1) Once release plan is complete, create an RC tag
> 2) Build an RC, consisting of source, binary distros, web site, etc.
> I like initial RCs to have "RC" in artifact names. Call me old
> fashioned, but I really do not like to create jars with final release
> names until I am pretty sure that is what is going to be released.
> 3) Announce availability of RC, publish RC-labeled jar to snapshot
> repo and tarballs to ~psteitz
> 3.5) Iterate 2), 3) 2-3 times until the community is happy with the results
> 4) Roll a "final" RC based on a "last" RC tag with
> destined-for-release bits in it (i.e. artifact names do not include
> "RC") and kick off a VOTE.
> 5) When the VOTE succeeds, copy the final RC tag to the release tag
> and move the *same signed voted bits* moved to the mirrors and rsynch
> maven repo.
>
> I don't know exactly what the release plugin does, but unless and
> until it does exactly those steps, I will do them manually. I have
> been able to get the candidate tarballs built using
> "mv -Prc site package assembly:assembly" Then I sign and move things.
> This is not a big problem for me. I don't mind grabbing the site from
> the tarballs and staging it manually to my home. This takes 20
> seconds and ensures that what we are reviewing / voting on the right
> content. The only part that is ugly / painful is doing 5) for the m2
> jar repos. A simple way to do that without hacking the metadata or
> having to regenerate the jars would be nice to have.
>
> Things I like to avoid:
> 1) altering tags
> 2) producing artifacts with the same names, but different contents
> (why I like to wait do do 4 until I am pretty certain the vote is
> going to pass).
> 3) allowing tag - artifact correspondence to be broken (i.e.
> one-to-one correspondence between immutable tags and artifacts, with
> artifacts always reproducible from tags).
>
> I don't think it is necessary for all commons release managers to use
> the same automation. We should try to make it as easy as possible for
> people to cut releases that meet our requirements, but I think RMs
> should have flexibility on what tools / approaches they want to use.
> The only *requirements* that we have are
>
> 1) We vote on final bits - i.e. what goes out to the mirrors is
> exactly what we VOTE on
> 2) Releases are (perpetually) reproducible from tags
> 3) Binaries must be buildable from source release packages
> 4) Release tars and zips must be published to the commons download site
> 5) Release jars - and *only release jars* - must be published to
> apache m2 rsynch repo
> 6) All ASF release requirements regarding sigs, licenses, notices,
> etc., must be satisfied
>
+1 to all of the above.
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/27/08, Phil Steitz <ph...@gmail.com> wrote:
> On Sat, Mar 22, 2008 at 9:23 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > On 3/22/08, Phil Steitz <ph...@gmail.com> wrote:
> > > On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <ws...@gmail.com> wrote:
> > > > On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <ph...@gmail.com> wrote:
> > > >
> > > > > 3) Announce availability of RC, publish RC-labeled jar to snapshot
> > > > > repo and tarballs to ~psteitz
> > > >
> > > > In order for (5) to be automated with the stage plugin, you would need
> > > > to stage each release in a separate repository. I think that's
> > > > already taken care of with the proposed changes to the parent pom
> > > > using space under people.a.o/builds/.
> > > >
> > > > (Non-snapshot artifacts shouldn't go in the snapshot repository,
> > > > though I'm probably responsible for starting that practice over at
> > > > Struts a long time ago.)
> > > >
> > >
> > > I don't see why it should be "illegal" to publish an RC to the
> > > snapshot repo. We do not distinguish "stable", "ga", "beta" etc here
> > > in Commons. We have releases and things that are not yet released. I
> > > don't see why we need yet another repo for RCs. We - at least I -
> > > like for people to test with our RCs *before* we vote on them. So
> > > maybe its just semantics and I am calling the RCs (with "RC" in the
> > > artifact name) "snapshots." I don't see the need to ask people to
> > > configure yet another special repo to test our RCs.
> > >
> > <snip/>
> >
> > For the style of RCs you've described, there is nothing against
> > putting them in the m2-snap-repo. But the final RC that you describe
> > is best not placed there, because:
> >
> > * Fundamentally, its a (soon-to-be) release, not a snap
> > * Wendy is alluding to a limitation of the stage plugin that requires
> > the staging repo to be clean (it will currently copy all versions that
> > exist in the staging repo over to the rsync repo! -- obviously that
> > means you don't want the m2-snap-repo to also be the staging repo
> > ATM). And for folks like me who won't be correcting metadata files by
> > hand (tedious, open to operator error), the stage plugin is needed.
> >
> > IMO, its not a bad idea to get folks to use an alternate repo for
> > testing RCs, it causes an increased level of awareness :-)
> >
>
>
> As long as there is a simple way for developers to test the RCs, I
> will be happy. I also do not like editing the metadata files, so if we
> can get the staging stuff to really work for the final release with no
> fear of badness or violating the tag <-> artifact binding, I will be
> happier still. Thanks!
>
<snip/>
We are going for happier still :-)
(thread seems to have fragmented a bit, I explained how I see this
working WRT m2-snap-repo so earlier RCs are easier to test in another
fragment)
-Rahul
>
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/1/08, James Carman <ja...@carmanconsulting.com> wrote:
> On Thu, Mar 27, 2008 at 1:45 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> > > It's almost like we need a two-phase commit here. We do some stuff
> > > and then ask everyone "are you okay with that?" What if we staged our
> > > releases to an SVN working copy? Then, everyone could look at it and
> > > if everyone was okay with it, we could commit the changes and that
> > > would somehow be updated in another "live" location on some periodic
> > > basis? I'm just thinking out loud here, so be gentle. :)
> > >
> > <snip/>
> >
> > I don't know if you meant to say working copy (AIUI, thats a private copy).
> >
> > In any case, this deviates sufficiently from the m2 release processes
> > around here for me to not want to look into it ATM :-)
>
>
> No, what I meant was that we'd have some working copy sitting around
> on the server somewhere for our m2 repository (and our distributions
> directory for that matter). Then, we would deploy to that working
> copy using m2 (which would update the metadata correctly and
> everything).
<snip/>
The stage plugin helps us with that (but has its own requirements
about staging repos ATM).
> Then, we vote on it. Then, if everything looks good,
> then someone commits it (may need a release management group or
> something for this). Then there would be some process that does an
> svn export to a directory that's rsynched to ibiblio. Again, I'm just
> thinking here. I kind of like the idea of having an SVN copy of our
> M2 repo and distributions directories.
>
OK, I meant to say this is a larger (set of) change(s). I'll take
smaller steps (when I get a chance) as outlined earlier. Shouldn't
preclude new ideas.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Mar 27, 2008 at 1:45 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> > It's almost like we need a two-phase commit here. We do some stuff
> > and then ask everyone "are you okay with that?" What if we staged our
> > releases to an SVN working copy? Then, everyone could look at it and
> > if everyone was okay with it, we could commit the changes and that
> > would somehow be updated in another "live" location on some periodic
> > basis? I'm just thinking out loud here, so be gentle. :)
> >
> <snip/>
>
> I don't know if you meant to say working copy (AIUI, thats a private copy).
>
> In any case, this deviates sufficiently from the m2 release processes
> around here for me to not want to look into it ATM :-)
No, what I meant was that we'd have some working copy sitting around
on the server somewhere for our m2 repository (and our distributions
directory for that matter). Then, we would deploy to that working
copy using m2 (which would update the metadata correctly and
everything). Then, we vote on it. Then, if everything looks good,
then someone commits it (may need a release management group or
something for this). Then there would be some process that does an
svn export to a directory that's rsynched to ibiblio. Again, I'm just
thinking here. I kind of like the idea of having an SVN copy of our
M2 repo and distributions directories.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/27/08, James Carman <ja...@carmanconsulting.com> wrote:
> On Thu, Mar 27, 2008 at 7:33 AM, sebb <se...@gmail.com> wrote:
> > It should be obvious that code uploaded to a personal user directory
> > has not been formally released.
> >
> > If a shared repository is used then this is less obvious, and there is
> > a risk that users will assume that it is a release. If a shared
> > repository is to be used for unreleased (development) code then it
> > needs to be very clearly identified as such, and the repository
> > location should not be published to users.
> >
>
>
> It's almost like we need a two-phase commit here. We do some stuff
> and then ask everyone "are you okay with that?" What if we staged our
> releases to an SVN working copy? Then, everyone could look at it and
> if everyone was okay with it, we could commit the changes and that
> would somehow be updated in another "live" location on some periodic
> basis? I'm just thinking out loud here, so be gentle. :)
>
<snip/>
I don't know if you meant to say working copy (AIUI, thats a private copy).
In any case, this deviates sufficiently from the m2 release processes
around here for me to not want to look into it ATM :-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Mar 27, 2008 at 7:33 AM, sebb <se...@gmail.com> wrote:
> It should be obvious that code uploaded to a personal user directory
> has not been formally released.
>
> If a shared repository is used then this is less obvious, and there is
> a risk that users will assume that it is a release. If a shared
> repository is to be used for unreleased (development) code then it
> needs to be very clearly identified as such, and the repository
> location should not be published to users.
>
It's almost like we need a two-phase commit here. We do some stuff
and then ask everyone "are you okay with that?" What if we staged our
releases to an SVN working copy? Then, everyone could look at it and
if everyone was okay with it, we could commit the changes and that
would somehow be updated in another "live" location on some periodic
basis? I'm just thinking out loud here, so be gentle. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/27/08, Phil Steitz <ph...@gmail.com> wrote:
> On Thu, Mar 27, 2008 at 4:33 AM, sebb <se...@gmail.com> wrote:
> >
>
> > On 27/03/2008, Phil Steitz <ph...@gmail.com> wrote:
> > > On Sat, Mar 22, 2008 at 9:23 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> > > >
<snip/>
> > > >
> > > > IMO, its not a bad idea to get folks to use an alternate repo for
> > > > testing RCs, it causes an increased level of awareness :-)
> > > >
<snap/>
There was a relevant additional post beyond this, but I will clarify
that it isn't one repo for all releases, its one repo per final RC
i.e. one per set of bits that go up for a vote. This is none different
than posting bits in ~s, which are one per vote repos.
> > >
> >
> > It should be obvious that code uploaded to a personal user directory
> > has not been formally released.
> >
> > If a shared repository is used then this is less obvious, and there is
> > a risk that users will assume that it is a release. If a shared
> > repository is to be used for unreleased (development) code then it
> > needs to be very clearly identified as such, and the repository
> > location should not be published to users.
> >
<snip/>
It is not a shared repository. It is a temporary / staging repository
so folks can look at the exact bits that will hit the m2 central repo
and its mirrors. This staging repo has the following brief lifecycle:
* Creation (when bits are "staged" ... i.e. 'mvn -Prc deploy')
* Examination (by those who intend to vote on these set of bits)
* Sync (moving to rsync repo if vote passes, use stage plugin here)
* Deletion (served its purpose in life, nuke it)
Note this is the way m2 releases are done in many other projects, its
not a new proposal.
As suggested initially, the URL of this temporary repo will be, for example,
http://pao/builds/commons/scxml/0.8/rc1 (clearly says rc)
instead of:
http://pao/~rahul/commons/scxml/0.8/rc1 (which is at RM's
discretion, may not even mention rc)
>
> This is why I put the RCs (without final release names) for testing in
> the snapshot repo, which is presented as a "development repo" and
> understood by the community to hold development snapshots for
> integration testing. I am OK developing another snapshot repo for RCs,
> but personally don't really get the need for it, other than to make it
> easier to stage releases.
>
<snap/>
Sure makes it easy to stage releases (see above on one repo per final
RC, not one snapshot repo for all RCs).
-Rahul
>
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Phil Steitz <ph...@gmail.com>.
On Thu, Mar 27, 2008 at 4:33 AM, sebb <se...@gmail.com> wrote:
>
> On 27/03/2008, Phil Steitz <ph...@gmail.com> wrote:
> > On Sat, Mar 22, 2008 at 9:23 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> > >
> > > On 3/22/08, Phil Steitz <ph...@gmail.com> wrote:
> > > > On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <ws...@gmail.com> wrote:
> > > > > On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <ph...@gmail.com> wrote:
> > > > >
> > > > > > 3) Announce availability of RC, publish RC-labeled jar to snapshot
> > > > > > repo and tarballs to ~psteitz
> > > > >
> > > > > In order for (5) to be automated with the stage plugin, you would need
> > > > > to stage each release in a separate repository. I think that's
> > > > > already taken care of with the proposed changes to the parent pom
> > > > > using space under people.a.o/builds/.
> > > > >
> > > > > (Non-snapshot artifacts shouldn't go in the snapshot repository,
> > > > > though I'm probably responsible for starting that practice over at
> > > > > Struts a long time ago.)
> > > > >
> > > >
> > > > I don't see why it should be "illegal" to publish an RC to the
> > > > snapshot repo. We do not distinguish "stable", "ga", "beta" etc here
> > > > in Commons. We have releases and things that are not yet released. I
> > > > don't see why we need yet another repo for RCs. We - at least I -
> > > > like for people to test with our RCs *before* we vote on them. So
> > > > maybe its just semantics and I am calling the RCs (with "RC" in the
> > > > artifact name) "snapshots." I don't see the need to ask people to
> > > > configure yet another special repo to test our RCs.
> > > >
> > > <snip/>
> > >
> > > For the style of RCs you've described, there is nothing against
> > > putting them in the m2-snap-repo. But the final RC that you describe
> > > is best not placed there, because:
> > >
> > > * Fundamentally, its a (soon-to-be) release, not a snap
> > > * Wendy is alluding to a limitation of the stage plugin that requires
> > > the staging repo to be clean (it will currently copy all versions that
> > > exist in the staging repo over to the rsync repo! -- obviously that
> > > means you don't want the m2-snap-repo to also be the staging repo
> > > ATM). And for folks like me who won't be correcting metadata files by
> > > hand (tedious, open to operator error), the stage plugin is needed.
> > >
> > > IMO, its not a bad idea to get folks to use an alternate repo for
> > > testing RCs, it causes an increased level of awareness :-)
> > >
> >
>
> It should be obvious that code uploaded to a personal user directory
> has not been formally released.
>
> If a shared repository is used then this is less obvious, and there is
> a risk that users will assume that it is a release. If a shared
> repository is to be used for unreleased (development) code then it
> needs to be very clearly identified as such, and the repository
> location should not be published to users.
>
This is why I put the RCs (without final release names) for testing in
the snapshot repo, which is presented as a "development repo" and
understood by the community to hold development snapshots for
integration testing. I am OK developing another snapshot repo for RCs,
but personally don't really get the need for it, other than to make it
easier to stage releases.
Phil
>
>
> > As long as there is a simple way for developers to test the RCs, I
> > will be happy. I also do not like editing the metadata files, so if we
> > can get the staging stuff to really work for the final release with no
> > fear of badness or violating the tag <-> artifact binding, I will be
> > happier still. Thanks!
> >
> >
> > Phil
> >
> >
> >
> > -------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by sebb <se...@gmail.com>.
On 27/03/2008, Phil Steitz <ph...@gmail.com> wrote:
> On Sat, Mar 22, 2008 at 9:23 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > On 3/22/08, Phil Steitz <ph...@gmail.com> wrote:
> > > On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <ws...@gmail.com> wrote:
> > > > On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <ph...@gmail.com> wrote:
> > > >
> > > > > 3) Announce availability of RC, publish RC-labeled jar to snapshot
> > > > > repo and tarballs to ~psteitz
> > > >
> > > > In order for (5) to be automated with the stage plugin, you would need
> > > > to stage each release in a separate repository. I think that's
> > > > already taken care of with the proposed changes to the parent pom
> > > > using space under people.a.o/builds/.
> > > >
> > > > (Non-snapshot artifacts shouldn't go in the snapshot repository,
> > > > though I'm probably responsible for starting that practice over at
> > > > Struts a long time ago.)
> > > >
> > >
> > > I don't see why it should be "illegal" to publish an RC to the
> > > snapshot repo. We do not distinguish "stable", "ga", "beta" etc here
> > > in Commons. We have releases and things that are not yet released. I
> > > don't see why we need yet another repo for RCs. We - at least I -
> > > like for people to test with our RCs *before* we vote on them. So
> > > maybe its just semantics and I am calling the RCs (with "RC" in the
> > > artifact name) "snapshots." I don't see the need to ask people to
> > > configure yet another special repo to test our RCs.
> > >
> > <snip/>
> >
> > For the style of RCs you've described, there is nothing against
> > putting them in the m2-snap-repo. But the final RC that you describe
> > is best not placed there, because:
> >
> > * Fundamentally, its a (soon-to-be) release, not a snap
> > * Wendy is alluding to a limitation of the stage plugin that requires
> > the staging repo to be clean (it will currently copy all versions that
> > exist in the staging repo over to the rsync repo! -- obviously that
> > means you don't want the m2-snap-repo to also be the staging repo
> > ATM). And for folks like me who won't be correcting metadata files by
> > hand (tedious, open to operator error), the stage plugin is needed.
> >
> > IMO, its not a bad idea to get folks to use an alternate repo for
> > testing RCs, it causes an increased level of awareness :-)
> >
>
It should be obvious that code uploaded to a personal user directory
has not been formally released.
If a shared repository is used then this is less obvious, and there is
a risk that users will assume that it is a release. If a shared
repository is to be used for unreleased (development) code then it
needs to be very clearly identified as such, and the repository
location should not be published to users.
>
> As long as there is a simple way for developers to test the RCs, I
> will be happy. I also do not like editing the metadata files, so if we
> can get the staging stuff to really work for the final release with no
> fear of badness or violating the tag <-> artifact binding, I will be
> happier still. Thanks!
>
>
> Phil
>
>
>
> -------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Phil Steitz <ph...@gmail.com>.
On Sat, Mar 22, 2008 at 9:23 PM, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 3/22/08, Phil Steitz <ph...@gmail.com> wrote:
> > On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <ws...@gmail.com> wrote:
> > > On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <ph...@gmail.com> wrote:
> > >
> > > > 3) Announce availability of RC, publish RC-labeled jar to snapshot
> > > > repo and tarballs to ~psteitz
> > >
> > > In order for (5) to be automated with the stage plugin, you would need
> > > to stage each release in a separate repository. I think that's
> > > already taken care of with the proposed changes to the parent pom
> > > using space under people.a.o/builds/.
> > >
> > > (Non-snapshot artifacts shouldn't go in the snapshot repository,
> > > though I'm probably responsible for starting that practice over at
> > > Struts a long time ago.)
> > >
> >
> > I don't see why it should be "illegal" to publish an RC to the
> > snapshot repo. We do not distinguish "stable", "ga", "beta" etc here
> > in Commons. We have releases and things that are not yet released. I
> > don't see why we need yet another repo for RCs. We - at least I -
> > like for people to test with our RCs *before* we vote on them. So
> > maybe its just semantics and I am calling the RCs (with "RC" in the
> > artifact name) "snapshots." I don't see the need to ask people to
> > configure yet another special repo to test our RCs.
> >
> <snip/>
>
> For the style of RCs you've described, there is nothing against
> putting them in the m2-snap-repo. But the final RC that you describe
> is best not placed there, because:
>
> * Fundamentally, its a (soon-to-be) release, not a snap
> * Wendy is alluding to a limitation of the stage plugin that requires
> the staging repo to be clean (it will currently copy all versions that
> exist in the staging repo over to the rsync repo! -- obviously that
> means you don't want the m2-snap-repo to also be the staging repo
> ATM). And for folks like me who won't be correcting metadata files by
> hand (tedious, open to operator error), the stage plugin is needed.
>
> IMO, its not a bad idea to get folks to use an alternate repo for
> testing RCs, it causes an increased level of awareness :-)
>
As long as there is a simple way for developers to test the RCs, I
will be happy. I also do not like editing the metadata files, so if we
can get the staging stuff to really work for the final release with no
fear of badness or violating the tag <-> artifact binding, I will be
happier still. Thanks!
Phil
-------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/25/08, sebb <se...@gmail.com> wrote:
> On 25/03/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> > On 3/24/08, sebb <se...@gmail.com> wrote:
> > <snip/>
> >
> > >
> > > I think someone needs to turn this thread into a document so it does
> > > not get lost ...
> > >
> >
> > <snap/>
> >
> > Sorry, I meant to elaborate when Phil mentioned documenting this as
> > well. The intent is to proceed in 3 steps:
> > * Discuss (this thread, will let it sit for a few more days)
>
>
> The document should be written at this point ...
>
<snip/>
:-) OK, swamped now, maybe next week, or atleast at ApacheCon.
> > * Act (pom changes in line with process discussed and with a JIRA for
> > each change, documenting on the wiki as changes are made, letting that
> > sit for a few)
>
>
> ... and updated here only as necessary to clarify it.
>
>
> > * Publish (release pom, add/update m2 section of release docs on cao site)
>
>
> So the Wiki working document will be replaced by a document on the site?
>
<snap/>
Yup, I believe thats a reasonable way to proceed. So augmenting this
(below) or perhaps a separate m2 specific page to accompany that. Will
be clearer where it fits once we see the text on the wiki.
http://commons.apache.org/releases/release.html
-Rahul
> I think the document needs to describe the purpose of the procedure as
> well as the steps needed to implement the procedure.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by sebb <se...@gmail.com>.
On 25/03/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On 3/24/08, sebb <se...@gmail.com> wrote:
> <snip/>
>
> >
> > I think someone needs to turn this thread into a document so it does
> > not get lost ...
> >
>
> <snap/>
>
> Sorry, I meant to elaborate when Phil mentioned documenting this as
> well. The intent is to proceed in 3 steps:
> * Discuss (this thread, will let it sit for a few more days)
The document should be written at this point ...
> * Act (pom changes in line with process discussed and with a JIRA for
> each change, documenting on the wiki as changes are made, letting that
> sit for a few)
... and updated here only as necessary to clarify it.
> * Publish (release pom, add/update m2 section of release docs on cao site)
So the Wiki working document will be replaced by a document on the site?
I think the document needs to describe the purpose of the procedure as
well as the steps needed to implement the procedure.
>
> -Rahul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/24/08, sebb <se...@gmail.com> wrote:
<snip/>
>
> I think someone needs to turn this thread into a document so it does
> not get lost ...
>
<snap/>
Sorry, I meant to elaborate when Phil mentioned documenting this as
well. The intent is to proceed in 3 steps:
* Discuss (this thread, will let it sit for a few more days)
* Act (pom changes in line with process discussed and with a JIRA for
each change, documenting on the wiki as changes are made, letting that
sit for a few)
* Publish (release pom, add/update m2 section of release docs on cao site)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by sebb <se...@gmail.com>.
On 24/03/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On 3/23/08, Phil Steitz <ph...@gmail.com> wrote:
> > On Sun, Mar 23, 2008 at 4:07 AM, James Carman
> > <ja...@carmanconsulting.com> wrote:
> > > On Sun, Mar 23, 2008 at 2:23 AM, Phil Steitz <ph...@gmail.com> wrote:
> > > > Right. I would not put the to-be-voted-on candidate there, just the
> > > > RCs leading up the the final, all of which have "RC" in their version
> > > > specs.
> > >
> > > From what I understand, we're not supposed to cut release candidates
> > > with "rc" in their version numbers. If you're going to cut a release
> > > candidate, then it's going to be up for a vote. That's why the
> > > version says something like "1.0" so that those exact bits can be
> > > deployed. At least, that's the way it was described to me when doing
> > > proxy.
> > >
> >
> > We have to VOTE on the final bits. It is perfectly fine - and IMO
> > advisable - to make RCs available for review prior to final VOTE. The
> > only hard and fast rule is that we vote on the final bits. Partly
> > for the reason that people's local repos end up with integrity
> > problems, I think it is a bad idea to have final version specs in
> > candidates used for testing and validation. One of the best things
> > about the Maven pom and repo structure is that got us away from
> > "commmons-foo.jar" naming and enforced the discipline that artifact
> > names, built into jar names, are unique and defining. Even just among
> > the development community we should try to stick to that, IMO.
> >
> > I may be odd man out here, but I see no reason that we should force
> > everyone to stop creating RCs for inspection prior to VOTE. If I have
> > to change the names to SNAPSHOT everywhere to make people happy, I
> > will do that, but as an RM I am not going to produce a sequence of
> > "candidate" jars all with the release name unless something really bad
> > surfaces in the final VOTE.
> >
>
> <snip/>
>
> Thats perfectly fine, IMO.
>
> Strictly from the perspective of a simpler m2 build, your offer of
> using "SNAPSHOT" (in addition to "RC") -- exact version details TBD --
> will work very well. That way, (the [B] equivalents of) ...
>
> mvn -Prc deploy
>
> ... will:
>
> * deploy to the m2-snap-repo for RCs with the above versioning
> scheme, which is what you'd prefer for the earlier RCs
>
> * deploy to a pao/builds special repo for the "final" RCs, which is
> what everyone should(!) prefer
>
> And for those creating all RCs with final versions, the first bullet
> doesn't hold.
>
> That way, on the topic of which style we should recommend to RMs, this
> thread (and subsequently, the build) can acknowledge both and remain
> agnostic.
>
I think someone needs to turn this thread into a document so it does
not get lost ...
>
> -Rahul
>
>
>
> >
> > Phil
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/23/08, Phil Steitz <ph...@gmail.com> wrote:
> On Sun, Mar 23, 2008 at 4:07 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
> > On Sun, Mar 23, 2008 at 2:23 AM, Phil Steitz <ph...@gmail.com> wrote:
> > > Right. I would not put the to-be-voted-on candidate there, just the
> > > RCs leading up the the final, all of which have "RC" in their version
> > > specs.
> >
> > From what I understand, we're not supposed to cut release candidates
> > with "rc" in their version numbers. If you're going to cut a release
> > candidate, then it's going to be up for a vote. That's why the
> > version says something like "1.0" so that those exact bits can be
> > deployed. At least, that's the way it was described to me when doing
> > proxy.
> >
>
> We have to VOTE on the final bits. It is perfectly fine - and IMO
> advisable - to make RCs available for review prior to final VOTE. The
> only hard and fast rule is that we vote on the final bits. Partly
> for the reason that people's local repos end up with integrity
> problems, I think it is a bad idea to have final version specs in
> candidates used for testing and validation. One of the best things
> about the Maven pom and repo structure is that got us away from
> "commmons-foo.jar" naming and enforced the discipline that artifact
> names, built into jar names, are unique and defining. Even just among
> the development community we should try to stick to that, IMO.
>
> I may be odd man out here, but I see no reason that we should force
> everyone to stop creating RCs for inspection prior to VOTE. If I have
> to change the names to SNAPSHOT everywhere to make people happy, I
> will do that, but as an RM I am not going to produce a sequence of
> "candidate" jars all with the release name unless something really bad
> surfaces in the final VOTE.
>
<snip/>
Thats perfectly fine, IMO.
Strictly from the perspective of a simpler m2 build, your offer of
using "SNAPSHOT" (in addition to "RC") -- exact version details TBD --
will work very well. That way, (the [B] equivalents of) ...
mvn -Prc deploy
... will:
* deploy to the m2-snap-repo for RCs with the above versioning
scheme, which is what you'd prefer for the earlier RCs
* deploy to a pao/builds special repo for the "final" RCs, which is
what everyone should(!) prefer
And for those creating all RCs with final versions, the first bullet
doesn't hold.
That way, on the topic of which style we should recommend to RMs, this
thread (and subsequently, the build) can acknowledge both and remain
agnostic.
-Rahul
>
> Phil
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Phil Steitz <ph...@gmail.com>.
On Sun, Mar 23, 2008 at 4:07 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Sun, Mar 23, 2008 at 2:23 AM, Phil Steitz <ph...@gmail.com> wrote:
> > Right. I would not put the to-be-voted-on candidate there, just the
> > RCs leading up the the final, all of which have "RC" in their version
> > specs.
>
> From what I understand, we're not supposed to cut release candidates
> with "rc" in their version numbers. If you're going to cut a release
> candidate, then it's going to be up for a vote. That's why the
> version says something like "1.0" so that those exact bits can be
> deployed. At least, that's the way it was described to me when doing
> proxy.
>
We have to VOTE on the final bits. It is perfectly fine - and IMO
advisable - to make RCs available for review prior to final VOTE. The
only hard and fast rule is that we vote on the final bits. Partly
for the reason that people's local repos end up with integrity
problems, I think it is a bad idea to have final version specs in
candidates used for testing and validation. One of the best things
about the Maven pom and repo structure is that got us away from
"commmons-foo.jar" naming and enforced the discipline that artifact
names, built into jar names, are unique and defining. Even just among
the development community we should try to stick to that, IMO.
I may be odd man out here, but I see no reason that we should force
everyone to stop creating RCs for inspection prior to VOTE. If I have
to change the names to SNAPSHOT everywhere to make people happy, I
will do that, but as an RM I am not going to produce a sequence of
"candidate" jars all with the release name unless something really bad
surfaces in the final VOTE.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Mar 23, 2008 at 2:23 AM, Phil Steitz <ph...@gmail.com> wrote:
> Right. I would not put the to-be-voted-on candidate there, just the
> RCs leading up the the final, all of which have "RC" in their version
> specs.
>From what I understand, we're not supposed to cut release candidates
with "rc" in their version numbers. If you're going to cut a release
candidate, then it's going to be up for a vote. That's why the
version says something like "1.0" so that those exact bits can be
deployed. At least, that's the way it was described to me when doing
proxy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Phil Steitz <ph...@gmail.com>.
> > I don't see why it should be "illegal" to publish an RC to the
> > snapshot repo. We do not distinguish "stable", "ga", "beta" etc here
> > in Commons. We have releases and things that are not yet released. I
> > don't see why we need yet another repo for RCs. We - at least I -
> > like for people to test with our RCs *before* we vote on them. So
> > maybe its just semantics and I am calling the RCs (with "RC" in the
> > artifact name) "snapshots." I don't see the need to ask people to
> > configure yet another special repo to test our RCs.
> >
> <snip/>
>
> For the style of RCs you've described, there is nothing against
> putting them in the m2-snap-repo. But the final RC that you describe
> is best not placed there, because:
>
> * Fundamentally, its a (soon-to-be) release, not a snap
Right. I would not put the to-be-voted-on candidate there, just the
RCs leading up the the final, all of which have "RC" in their version
specs.
> * Wendy is alluding to a limitation of the stage plugin that requires
> the staging repo to be clean (it will currently copy all versions that
> exist in the staging repo over to the rsync repo! -- obviously that
> means you don't want the m2-snap-repo to also be the staging repo
> ATM). And for folks like me who won't be correcting metadata files by
> hand (tedious, open to operator error), the stage plugin is needed.
>
> IMO, its not a bad idea to get folks to use an alternate repo for
> testing RCs, it causes an increased level of awareness :-)
>
I just want to make it as simple as possible for developers to test
our RCs and I think having "RC" in the artifact name is enough to
ensure people know what they are testing.
I want to do everything possible to encourage development community
testing of release candidates. I think we do a good job - maybe even
too good a job - validating structure, formal contents and doing
static code analysis of release packages and I would like to see more
of that energy applied to validating the code itself from a functional
standpoint.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/22/08, Phil Steitz <ph...@gmail.com> wrote:
> On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <ws...@gmail.com> wrote:
> > On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <ph...@gmail.com> wrote:
> >
> > > 3) Announce availability of RC, publish RC-labeled jar to snapshot
> > > repo and tarballs to ~psteitz
> >
> > In order for (5) to be automated with the stage plugin, you would need
> > to stage each release in a separate repository. I think that's
> > already taken care of with the proposed changes to the parent pom
> > using space under people.a.o/builds/.
> >
> > (Non-snapshot artifacts shouldn't go in the snapshot repository,
> > though I'm probably responsible for starting that practice over at
> > Struts a long time ago.)
> >
>
> I don't see why it should be "illegal" to publish an RC to the
> snapshot repo. We do not distinguish "stable", "ga", "beta" etc here
> in Commons. We have releases and things that are not yet released. I
> don't see why we need yet another repo for RCs. We - at least I -
> like for people to test with our RCs *before* we vote on them. So
> maybe its just semantics and I am calling the RCs (with "RC" in the
> artifact name) "snapshots." I don't see the need to ask people to
> configure yet another special repo to test our RCs.
>
<snip/>
For the style of RCs you've described, there is nothing against
putting them in the m2-snap-repo. But the final RC that you describe
is best not placed there, because:
* Fundamentally, its a (soon-to-be) release, not a snap
* Wendy is alluding to a limitation of the stage plugin that requires
the staging repo to be clean (it will currently copy all versions that
exist in the staging repo over to the rsync repo! -- obviously that
means you don't want the m2-snap-repo to also be the staging repo
ATM). And for folks like me who won't be correcting metadata files by
hand (tedious, open to operator error), the stage plugin is needed.
IMO, its not a bad idea to get folks to use an alternate repo for
testing RCs, it causes an increased level of awareness :-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Phil Steitz <ph...@gmail.com>.
On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <ph...@gmail.com> wrote:
>
> > 3) Announce availability of RC, publish RC-labeled jar to snapshot
> > repo and tarballs to ~psteitz
>
> In order for (5) to be automated with the stage plugin, you would need
> to stage each release in a separate repository. I think that's
> already taken care of with the proposed changes to the parent pom
> using space under people.a.o/builds/.
>
> (Non-snapshot artifacts shouldn't go in the snapshot repository,
> though I'm probably responsible for starting that practice over at
> Struts a long time ago.)
>
I don't see why it should be "illegal" to publish an RC to the
snapshot repo. We do not distinguish "stable", "ga", "beta" etc here
in Commons. We have releases and things that are not yet released. I
don't see why we need yet another repo for RCs. We - at least I -
like for people to test with our RCs *before* we vote on them. So
maybe its just semantics and I am calling the RCs (with "RC" in the
artifact name) "snapshots." I don't see the need to ask people to
configure yet another special repo to test our RCs.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Wendy Smoak <ws...@gmail.com>.
On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <ph...@gmail.com> wrote:
> 3) Announce availability of RC, publish RC-labeled jar to snapshot
> repo and tarballs to ~psteitz
In order for (5) to be automated with the stage plugin, you would need
to stage each release in a separate repository. I think that's
already taken care of with the proposed changes to the parent pom
using space under people.a.o/builds/.
(Non-snapshot artifacts shouldn't go in the snapshot repository,
though I'm probably responsible for starting that practice over at
Struts a long time ago.)
> 5) When the VOTE succeeds, copy the final RC tag to the release tag
> and move the *same signed voted bits* moved to the mirrors and rsynch
> maven repo.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/22/08, Niall Pemberton <ni...@gmail.com> wrote:
> On Sat, Mar 22, 2008 at 10:10 PM, Phil Steitz <ph...@gmail.com> wrote:
<snip/>
> >
> > Keeping things at the "vision" level, what I like to do is
> >
> > 1) Once release plan is complete, create an RC tag
> > 2) Build an RC, consisting of source, binary distros, web site, etc.
> > I like initial RCs to have "RC" in artifact names. Call me old
> > fashioned, but I really do not like to create jars with final release
> > names until I am pretty sure that is what is going to be released.
> > 3) Announce availability of RC, publish RC-labeled jar to snapshot
> > repo and tarballs to ~psteitz
> > 3.5) Iterate 2), 3) 2-3 times until the community is happy with the results
>
>
> Shouldn't that be "Iterate 1), 2), 3)" - i.e. tag for each RC?
>
>
> > 4) Roll a "final" RC based on a "last" RC tag with
> > destined-for-release bits in it (i.e. artifact names do not include
> > "RC") and kick off a VOTE.
> > 5) When the VOTE succeeds, copy the final RC tag to the release tag
> > and move the *same signed voted bits* moved to the mirrors and rsynch
> > maven repo.
> >
> > I don't know exactly what the release plugin does, but unless and
> > until it does exactly those steps, I will do them manually.
>
>
> +1
>
>
> > I have been able to get the candidate tarballs built using
> > "mv -Prc site package assembly:assembly" Then I sign and move things.
>
>
> Since version 9 of commons-parent you can just do "mvn -Prc package"
> - the "site" and "assembly" goals are run as part of the package phase
> for the "rc" profile. My variation is I do "mvn -Prc install" -
> because it creates the md5/sha1 checksums and signatures as well (the
> only downside is the you have to go to your local repo to find the
> checksums).
>
<snap/>
And the next step in that logical progression is "mvn -Prc deploy"
(variants in [B]) which posts everything to a remote staging
repository, ready for inspection by the greater community.
I tried this for a snapshot build a few days ago (works great,
thanks!), though I haven't inspected the artifacts myself yet:
http://people.apache.org/repo/m2-snapshot-repository/commons-scxml/commons-scxml/0.8-SNAPSHOT/
>
> > This is not a big problem for me. I don't mind grabbing the site from
> > the tarballs and staging it manually to my home. This takes 20
> > seconds and ensures that what we are reviewing / voting on the right
> > content. The only part that is ugly / painful is doing 5) for the m2
> > jar repos. A simple way to do that without hacking the metadata or
> > having to regenerate the jars would be nice to have.
> >
> > Things I like to avoid:
> > 1) altering tags
> > 2) producing artifacts with the same names, but different contents
> > (why I like to wait do do 4 until I am pretty certain the vote is
> > going to pass).
> > 3) allowing tag - artifact correspondence to be broken (i.e.
> > one-to-one correspondence between immutable tags and artifacts, with
> > artifacts always reproducible from tags).
> >
> > I don't think it is necessary for all commons release managers to use
> > the same automation. We should try to make it as easy as possible for
> > people to cut releases that meet our requirements, but I think RMs
> > should have flexibility on what tools / approaches they want to use.
>
>
> +1, I haven't been doing your RC bit - all the RC's have the proper
> version number. I guess I'm always optimistic that the 1st RC is going
> to succeed :)
>
>
> > The only *requirements* that we have are
> >
> > 1) We vote on final bits - i.e. what goes out to the mirrors is
> > exactly what we VOTE on
> > 2) Releases are (perpetually) reproducible from tags
> > 3) Binaries must be buildable from source release packages
> > 4) Release tars and zips must be published to the commons download site
> > 5) Release jars - and *only release jars* - must be published to
> > apache m2 rsynch repo
>
>
> I think that should be *only release jars, the pom and their
> signatures/checksums*.
>
>
> > 6) All ASF release requirements regarding sigs, licenses, notices,
> > etc., must be satisfied
>
<snip/>
Indeed, we wouldn't settle for anything less, whatever the tools :-)
(WRT the 6 items above)
>
> At some point I think we should add "releases are built with m2" to
> the above list of requirements. Besides m1 becoming more obsolete, I
> think making releases "OSGi ready" (which the m2 build does) tips the
> balance. I guess the question is are people happy to make that
> official policy now or are there objections?
>
<snap/>
While I agree that such policy will streamline much of the release
processes, I care more about the end effect than the means, which I'd
rather leave to the RM. I will continue to support releases cut using
m1 (or ant), as long as they meet the fundamental requirements for a
good release.
This discussion was initiated because unless most of us planning on
using m2 form a collective cutting releases process vision, we'll be
pulling the parent pom(s) in different directions.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 22, 2008 at 10:10 PM, Phil Steitz <ph...@gmail.com> wrote:
> First, thanks for helping move this along, Rahul. We need to at least
> get the "releasing" docs updated.
>
> On Fri, Mar 21, 2008 at 3:41 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> > Based on couple of JIRA comments, it seems there still isn't consensus
> > about a release process using m2 at Commons. I'll try to outline the
> > process.
> >
> > <outline>
> >
> > [A] Release prep
> >
> > [B] Stage artifacts and site, to some location TBD (entire commands
> > below, not abridged etc.):
> >
> > mvn -Prc release:prepare
> > mvn -Prc release:perform
> > mvn -Prc site-deploy
> >
> > Or, if you don't care about the release plugin, after setting final
> > versions in [A]:
> >
> > mvn -Prc deploy
> > mvn -Prc site-deploy
> >
> > [C] Vote
> >
> > [D] Go live
> >
> > mvn stage:copy ...
> > mvn site-deploy
> >
> > </outline>
> >
> > Does this fit your mental model? If not, why not?
> >
> > Please keep the discussion at a "vision" level. Yes, the outline is
> > flawed (all votes don't pass, there are loops etc.) Yes, required pom
> > changes are not discussed. But, once process is OK'ed, we will make
> > the poms do the right thing :-)
>
> Keeping things at the "vision" level, what I like to do is
>
> 1) Once release plan is complete, create an RC tag
> 2) Build an RC, consisting of source, binary distros, web site, etc.
> I like initial RCs to have "RC" in artifact names. Call me old
> fashioned, but I really do not like to create jars with final release
> names until I am pretty sure that is what is going to be released.
> 3) Announce availability of RC, publish RC-labeled jar to snapshot
> repo and tarballs to ~psteitz
> 3.5) Iterate 2), 3) 2-3 times until the community is happy with the results
Shouldn't that be "Iterate 1), 2), 3)" - i.e. tag for each RC?
> 4) Roll a "final" RC based on a "last" RC tag with
> destined-for-release bits in it (i.e. artifact names do not include
> "RC") and kick off a VOTE.
> 5) When the VOTE succeeds, copy the final RC tag to the release tag
> and move the *same signed voted bits* moved to the mirrors and rsynch
> maven repo.
>
> I don't know exactly what the release plugin does, but unless and
> until it does exactly those steps, I will do them manually.
+1
> I have been able to get the candidate tarballs built using
> "mv -Prc site package assembly:assembly" Then I sign and move things.
Since version 9 of commons-parent you can just do "mvn -Prc package"
- the "site" and "assembly" goals are run as part of the package phase
for the "rc" profile. My variation is I do "mvn -Prc install" -
because it creates the md5/sha1 checksums and signatures as well (the
only downside is the you have to go to your local repo to find the
checksums).
> This is not a big problem for me. I don't mind grabbing the site from
> the tarballs and staging it manually to my home. This takes 20
> seconds and ensures that what we are reviewing / voting on the right
> content. The only part that is ugly / painful is doing 5) for the m2
> jar repos. A simple way to do that without hacking the metadata or
> having to regenerate the jars would be nice to have.
>
> Things I like to avoid:
> 1) altering tags
> 2) producing artifacts with the same names, but different contents
> (why I like to wait do do 4 until I am pretty certain the vote is
> going to pass).
> 3) allowing tag - artifact correspondence to be broken (i.e.
> one-to-one correspondence between immutable tags and artifacts, with
> artifacts always reproducible from tags).
>
> I don't think it is necessary for all commons release managers to use
> the same automation. We should try to make it as easy as possible for
> people to cut releases that meet our requirements, but I think RMs
> should have flexibility on what tools / approaches they want to use.
+1, I haven't been doing your RC bit - all the RC's have the proper
version number. I guess I'm always optimistic that the 1st RC is going
to succeed :)
> The only *requirements* that we have are
>
> 1) We vote on final bits - i.e. what goes out to the mirrors is
> exactly what we VOTE on
> 2) Releases are (perpetually) reproducible from tags
> 3) Binaries must be buildable from source release packages
> 4) Release tars and zips must be published to the commons download site
> 5) Release jars - and *only release jars* - must be published to
> apache m2 rsynch repo
I think that should be *only release jars, the pom and their
signatures/checksums*.
> 6) All ASF release requirements regarding sigs, licenses, notices,
> etc., must be satisfied
At some point I think we should add "releases are built with m2" to
the above list of requirements. Besides m1 becoming more obsolete, I
think making releases "OSGi ready" (which the m2 build does) tips the
balance. I guess the question is are people happy to make that
official policy now or are there objections?
Niall
> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Phil Steitz <ph...@gmail.com>.
First, thanks for helping move this along, Rahul. We need to at least
get the "releasing" docs updated.
On Fri, Mar 21, 2008 at 3:41 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> Based on couple of JIRA comments, it seems there still isn't consensus
> about a release process using m2 at Commons. I'll try to outline the
> process.
>
> <outline>
>
> [A] Release prep
>
> [B] Stage artifacts and site, to some location TBD (entire commands
> below, not abridged etc.):
>
> mvn -Prc release:prepare
> mvn -Prc release:perform
> mvn -Prc site-deploy
>
> Or, if you don't care about the release plugin, after setting final
> versions in [A]:
>
> mvn -Prc deploy
> mvn -Prc site-deploy
>
> [C] Vote
>
> [D] Go live
>
> mvn stage:copy ...
> mvn site-deploy
>
> </outline>
>
> Does this fit your mental model? If not, why not?
>
> Please keep the discussion at a "vision" level. Yes, the outline is
> flawed (all votes don't pass, there are loops etc.) Yes, required pom
> changes are not discussed. But, once process is OK'ed, we will make
> the poms do the right thing :-)
Keeping things at the "vision" level, what I like to do is
1) Once release plan is complete, create an RC tag
2) Build an RC, consisting of source, binary distros, web site, etc.
I like initial RCs to have "RC" in artifact names. Call me old
fashioned, but I really do not like to create jars with final release
names until I am pretty sure that is what is going to be released.
3) Announce availability of RC, publish RC-labeled jar to snapshot
repo and tarballs to ~psteitz
3.5) Iterate 2), 3) 2-3 times until the community is happy with the results
4) Roll a "final" RC based on a "last" RC tag with
destined-for-release bits in it (i.e. artifact names do not include
"RC") and kick off a VOTE.
5) When the VOTE succeeds, copy the final RC tag to the release tag
and move the *same signed voted bits* moved to the mirrors and rsynch
maven repo.
I don't know exactly what the release plugin does, but unless and
until it does exactly those steps, I will do them manually. I have
been able to get the candidate tarballs built using
"mv -Prc site package assembly:assembly" Then I sign and move things.
This is not a big problem for me. I don't mind grabbing the site from
the tarballs and staging it manually to my home. This takes 20
seconds and ensures that what we are reviewing / voting on the right
content. The only part that is ugly / painful is doing 5) for the m2
jar repos. A simple way to do that without hacking the metadata or
having to regenerate the jars would be nice to have.
Things I like to avoid:
1) altering tags
2) producing artifacts with the same names, but different contents
(why I like to wait do do 4 until I am pretty certain the vote is
going to pass).
3) allowing tag - artifact correspondence to be broken (i.e.
one-to-one correspondence between immutable tags and artifacts, with
artifacts always reproducible from tags).
I don't think it is necessary for all commons release managers to use
the same automation. We should try to make it as easy as possible for
people to cut releases that meet our requirements, but I think RMs
should have flexibility on what tools / approaches they want to use.
The only *requirements* that we have are
1) We vote on final bits - i.e. what goes out to the mirrors is
exactly what we VOTE on
2) Releases are (perpetually) reproducible from tags
3) Binaries must be buildable from source release packages
4) Release tars and zips must be published to the commons download site
5) Release jars - and *only release jars* - must be published to
apache m2 rsynch repo
6) All ASF release requirements regarding sigs, licenses, notices,
etc., must be satisfied
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
As a somewhat new topic, but seems reasonable in the same thread, I'm
interested in eliminating the dichotomy of using m2 to release poms
vs. components. We discussed we'll start staging skins, this will mean
extending that to poms.
Operationally, this will mean that the process (and m2 commands)
mentioned at the top of this thread will consistently be used for all
releases (be it poms or components). Other benefits: staging (we can
watch license headers, for example), a simpler pom (no need for
release profile, which mostly overlaps with the rc profile).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by James Carman <ja...@carmanconsulting.com>.
On Sat, Mar 22, 2008 at 1:56 PM, simon <si...@chello.at> wrote:
> (b)
> maven-release-plugin checks that there are no SNAPSHOT versions in the
> pom.
>
> But isn't
> grep "SNAPSHOT" pom.xml
> simple enough? [1]
>
>
Perhaps we could use the enforcer plugin once it gets all the kinks
out? It has a rule that says "no SNAPSHOT dependencies." We could
put the enforcer plugin only in the rc/release profiles.
> (c)
> maven-release-plugin creates a tag for you.
>
> Oh yay. Isn't "svn cp" easy enough?
>
> Anyway, I prefer to create an svn cp in a "branches" directory, then do
> the release from there, and move it to the tags dir once the release has
> worked. With that approach, there is never a window where the tags dir
> contains something marked as a release when the release has not yet
> happened.
>
+1. I like the release-preparation branch approach, too. That worked
out quite well for me when doing proxy's 1.0 release, especially since
I had to do so many release candidates. :)
> (d)
> maven-release-plugin updates the version number in the pom.
>
> Oh yay. Isn't edit/commit enough?
>
It would be nice if the release plugin just split out its
functionality into simple commands, like release:increment-version
(since that can be useful in multi-module builds).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/22/08, Dennis Lundberg <de...@apache.org> wrote:
<snip/>
>
> I haven't read all the text below, and I refuse to do so, until we can
> reach an agreement on a "vision" level.
>
<snap/>
FWIW, I think we are doing OK at that level. Atleast enough to make
progress on COMMONSSITE-{26,27}, which is my short term objective
here.
I think the release plugin discussion would be better served in its
own thread from here on.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Dennis Lundberg <de...@apache.org>.
What happened to the "vision" level that Rahul requested that we stay on?
This happens *every* time we get into discussions about the build or
release process. Instead of focusing on what we can agree upon people
start going into the nitty gritty details saying: I *don't* like this or
that detail. It's *so* unproductive it makes me sick.
I haven't read all the text below, and I refuse to do so, until we can
reach an agreement on a "vision" level.
simon wrote:
> On Sat, 2008-03-22 at 18:18 +0100, Dennis Lundberg wrote:
>> James Carman wrote:
>>> On 3/21/08, Dennis Lundberg <de...@apache.org> wrote:
>>>> If I raise my view and just look at the A, B, C and D headings, it
>>>> sounds good. But, there shouldn't be two options under B. IMO we should
>>>> always use the release plugin. That will give us consistent releases.
>>>>
>>>> Should something be wrong with the release-plugin we'll be consistently
>>>> wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
>>>> in the long run.
>>>>
>>> Another thing to consider is that the release plugin isn't written
>>> specifically for apache commons or the ASF in general, nor should it
>>> be. Maven is designed to be a general-purpose build system for all
>>> projects. We could consider writing our own release plugin which
>>> enforces/supports our release process. It shouldn't be that tough, if
>>> that's what it comes down to. I think the maven release plugin's
>>> philosophy of cutting/deploying releases differs from ours.
>> Let us first decide what our release philosophy is, and worry about
>> finding the right tools later.
>>
>
> I personally dislike the maven-release-plugin a lot.
>
> It does a number of tasks that can be done simply by hand.
> It does a number of tasks that are just pointless for us.
>
> But the worst part is that it deals with version-control using the
> "least-common-denominator" approach, ie treats svn as if it were cvs.
> This causes unnecessary commits, and makes handling a failed release
> much uglier than it needs to be.
>
> And it's just plain opaque. People should not have to spend time
> learning to use a tool that does something that they could have done
> just as easily themselves. Particularly as releases are only done
> infrequently.
>
> [1] Ok, I admit that when releasing a whole tree of modules it might
> save some effort, ie a pom that has a lot of <module> tags pointing at
> modules in subdirs. But we don't have that in commons.
>
> Here's the tasks that "release prepare" does:
>
> http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html
>
> (a)
> check for uncommitted code
>
> Hopefully everyone already does releases from a freshly-checked-out
> directory. That should be part of the release document, in which case
> this step is pointless.
>
> Otherwise "svn status" does the trick. Ok, you have to remember to do
> it.
>
>
> (b)
> maven-release-plugin checks that there are no SNAPSHOT versions in the
> pom.
>
> But isn't
> grep "SNAPSHOT" pom.xml
> simple enough? [1]
>
>
> (c)
> maven-release-plugin creates a tag for you.
>
> Oh yay. Isn't "svn cp" easy enough?
>
> Anyway, I prefer to create an svn cp in a "branches" directory, then do
> the release from there, and move it to the tags dir once the release has
> worked. With that approach, there is never a window where the tags dir
> contains something marked as a release when the release has not yet
> happened.
>
> (d)
> maven-release-plugin updates the version number in the pom.
>
> Oh yay. Isn't edit/commit enough?
>
> Anyway, what it does is update the version in trunk, then create the
> tag, then update the version in trunk again. Ecch. I think this is
> because it is trying to be cvs-compatible.
>
> It is nicer to create a branch, update in trunk to (v+1)-SNAPSHOT, and
> update in trunk to remove the SNAPSHOT. Clearer to all watching the
> commit logs what is happening.
>
> And if a release needs to be "undone", maven-release-plugin then adds a
> new commit to trunk to rewind the version number. But with svn, we on't
> need to do that. We can just revert the "release preparation branch" we
> created, or svn cp a specific version of trunk.
>
> (e)
> Update the scm link, from pointing at trunk to pointing at the tag dir.
>
> Actually, I don't think this is very useful. Pointing at the trunk is
> probably better, particularly when a release includes source jars
> already.
>
> (f)
> Run all tests against the modified pom.
>
> Well, if a "release branch" approach is used, then that happens
> automatically when the release candidate code is built.
>
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by simon <si...@chello.at>.
On Sat, 2008-03-22 at 18:18 +0100, Dennis Lundberg wrote:
> James Carman wrote:
> > On 3/21/08, Dennis Lundberg <de...@apache.org> wrote:
> >> If I raise my view and just look at the A, B, C and D headings, it
> >> sounds good. But, there shouldn't be two options under B. IMO we should
> >> always use the release plugin. That will give us consistent releases.
> >>
> >> Should something be wrong with the release-plugin we'll be consistently
> >> wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
> >> in the long run.
> >>
> >
> > Another thing to consider is that the release plugin isn't written
> > specifically for apache commons or the ASF in general, nor should it
> > be. Maven is designed to be a general-purpose build system for all
> > projects. We could consider writing our own release plugin which
> > enforces/supports our release process. It shouldn't be that tough, if
> > that's what it comes down to. I think the maven release plugin's
> > philosophy of cutting/deploying releases differs from ours.
>
> Let us first decide what our release philosophy is, and worry about
> finding the right tools later.
>
I personally dislike the maven-release-plugin a lot.
It does a number of tasks that can be done simply by hand.
It does a number of tasks that are just pointless for us.
But the worst part is that it deals with version-control using the
"least-common-denominator" approach, ie treats svn as if it were cvs.
This causes unnecessary commits, and makes handling a failed release
much uglier than it needs to be.
And it's just plain opaque. People should not have to spend time
learning to use a tool that does something that they could have done
just as easily themselves. Particularly as releases are only done
infrequently.
[1] Ok, I admit that when releasing a whole tree of modules it might
save some effort, ie a pom that has a lot of <module> tags pointing at
modules in subdirs. But we don't have that in commons.
Here's the tasks that "release prepare" does:
http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html
(a)
check for uncommitted code
Hopefully everyone already does releases from a freshly-checked-out
directory. That should be part of the release document, in which case
this step is pointless.
Otherwise "svn status" does the trick. Ok, you have to remember to do
it.
(b)
maven-release-plugin checks that there are no SNAPSHOT versions in the
pom.
But isn't
grep "SNAPSHOT" pom.xml
simple enough? [1]
(c)
maven-release-plugin creates a tag for you.
Oh yay. Isn't "svn cp" easy enough?
Anyway, I prefer to create an svn cp in a "branches" directory, then do
the release from there, and move it to the tags dir once the release has
worked. With that approach, there is never a window where the tags dir
contains something marked as a release when the release has not yet
happened.
(d)
maven-release-plugin updates the version number in the pom.
Oh yay. Isn't edit/commit enough?
Anyway, what it does is update the version in trunk, then create the
tag, then update the version in trunk again. Ecch. I think this is
because it is trying to be cvs-compatible.
It is nicer to create a branch, update in trunk to (v+1)-SNAPSHOT, and
update in trunk to remove the SNAPSHOT. Clearer to all watching the
commit logs what is happening.
And if a release needs to be "undone", maven-release-plugin then adds a
new commit to trunk to rewind the version number. But with svn, we on't
need to do that. We can just revert the "release preparation branch" we
created, or svn cp a specific version of trunk.
(e)
Update the scm link, from pointing at trunk to pointing at the tag dir.
Actually, I don't think this is very useful. Pointing at the trunk is
probably better, particularly when a release includes source jars
already.
(f)
Run all tests against the modified pom.
Well, if a "release branch" approach is used, then that happens
automatically when the release candidate code is built.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Dennis Lundberg <de...@apache.org>.
James Carman wrote:
> On 3/21/08, Dennis Lundberg <de...@apache.org> wrote:
>> If I raise my view and just look at the A, B, C and D headings, it
>> sounds good. But, there shouldn't be two options under B. IMO we should
>> always use the release plugin. That will give us consistent releases.
>>
>> Should something be wrong with the release-plugin we'll be consistently
>> wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
>> in the long run.
>>
>
> Another thing to consider is that the release plugin isn't written
> specifically for apache commons or the ASF in general, nor should it
> be. Maven is designed to be a general-purpose build system for all
> projects. We could consider writing our own release plugin which
> enforces/supports our release process. It shouldn't be that tough, if
> that's what it comes down to. I think the maven release plugin's
> philosophy of cutting/deploying releases differs from ours.
Let us first decide what our release philosophy is, and worry about
finding the right tools later.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/21/08, James Carman <ja...@carmanconsulting.com> wrote:
> On 3/21/08, Dennis Lundberg <de...@apache.org> wrote:
> > If I raise my view and just look at the A, B, C and D headings, it
> > sounds good. But, there shouldn't be two options under B. IMO we should
> > always use the release plugin. That will give us consistent releases.
> >
> > Should something be wrong with the release-plugin we'll be consistently
> > wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
> > in the long run.
> >
>
>
> Another thing to consider is that the release plugin isn't written
> specifically for apache commons or the ASF in general, nor should it
> be. Maven is designed to be a general-purpose build system for all
> projects. We could consider writing our own release plugin which
> enforces/supports our release process. It shouldn't be that tough, if
> that's what it comes down to. I think the maven release plugin's
> philosophy of cutting/deploying releases differs from ours.
>
<snip/>
I believe with the release of the maven-stage-plugin (a month or so
ago), we may be in decent shape and not need to roll anything (but,
yes, thats an option if needed). The release plugin can do relevant
bits in [B] and the stage plugin relevant bits in [D].
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by James Carman <ja...@carmanconsulting.com>.
On 3/21/08, Dennis Lundberg <de...@apache.org> wrote:
> If I raise my view and just look at the A, B, C and D headings, it
> sounds good. But, there shouldn't be two options under B. IMO we should
> always use the release plugin. That will give us consistent releases.
>
> Should something be wrong with the release-plugin we'll be consistently
> wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
> in the long run.
>
Another thing to consider is that the release plugin isn't written
specifically for apache commons or the ASF in general, nor should it
be. Maven is designed to be a general-purpose build system for all
projects. We could consider writing our own release plugin which
enforces/supports our release process. It shouldn't be that tough, if
that's what it comes down to. I think the maven release plugin's
philosophy of cutting/deploying releases differs from ours.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Dennis Lundberg <de...@apache.org>.
Rahul Akolkar wrote:
> On 3/21/08, Dennis Lundberg <de...@apache.org> wrote:
>> If I raise my view and just look at the A, B, C and D headings, it
>> sounds good. But, there shouldn't be two options under B. IMO we should
>> always use the release plugin. That will give us consistent releases.
>>
> <snip/>
>
> Or consistently not using it ;-) But in hindsight, I shouldn't have
> put that option in [B] on the table since its serving as a
> distraction. I am OK with removing it.
Right, there should only be one way to do it. If that way involves the
release-plugin or not will be decided later on.
>
> -Rahul
>
>
>> Should something be wrong with the release-plugin we'll be consistently
>> wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
>> in the long run.
>>
>>
>>
>> Rahul Akolkar wrote:
>> > Based on couple of JIRA comments, it seems there still isn't consensus
>> > about a release process using m2 at Commons. I'll try to outline the
>> > process.
>> >
>> > <outline>
>> >
>> > [A] Release prep
>> >
>> > [B] Stage artifacts and site, to some location TBD (entire commands
>> > below, not abridged etc.):
>> >
>> > mvn -Prc release:prepare
>> > mvn -Prc release:perform
>> > mvn -Prc site-deploy
>> >
>> > Or, if you don't care about the release plugin, after setting final
>> > versions in [A]:
>> >
>> > mvn -Prc deploy
>> > mvn -Prc site-deploy
>> >
>> > [C] Vote
>> >
>> > [D] Go live
>> >
>> > mvn stage:copy ...
>> > mvn site-deploy
>> >
>> > </outline>
>> >
>> > Does this fit your mental model? If not, why not?
>> >
>> > Please keep the discussion at a "vision" level. Yes, the outline is
>> > flawed (all votes don't pass, there are loops etc.) Yes, required pom
>> > changes are not discussed. But, once process is OK'ed, we will make
>> > the poms do the right thing :-)
>> >
>> > -Rahul
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/21/08, Dennis Lundberg <de...@apache.org> wrote:
> If I raise my view and just look at the A, B, C and D headings, it
> sounds good. But, there shouldn't be two options under B. IMO we should
> always use the release plugin. That will give us consistent releases.
>
<snip/>
Or consistently not using it ;-) But in hindsight, I shouldn't have
put that option in [B] on the table since its serving as a
distraction. I am OK with removing it.
-Rahul
> Should something be wrong with the release-plugin we'll be consistently
> wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
> in the long run.
>
>
>
> Rahul Akolkar wrote:
> > Based on couple of JIRA comments, it seems there still isn't consensus
> > about a release process using m2 at Commons. I'll try to outline the
> > process.
> >
> > <outline>
> >
> > [A] Release prep
> >
> > [B] Stage artifacts and site, to some location TBD (entire commands
> > below, not abridged etc.):
> >
> > mvn -Prc release:prepare
> > mvn -Prc release:perform
> > mvn -Prc site-deploy
> >
> > Or, if you don't care about the release plugin, after setting final
> > versions in [A]:
> >
> > mvn -Prc deploy
> > mvn -Prc site-deploy
> >
> > [C] Vote
> >
> > [D] Go live
> >
> > mvn stage:copy ...
> > mvn site-deploy
> >
> > </outline>
> >
> > Does this fit your mental model? If not, why not?
> >
> > Please keep the discussion at a "vision" level. Yes, the outline is
> > flawed (all votes don't pass, there are loops etc.) Yes, required pom
> > changes are not discussed. But, once process is OK'ed, we will make
> > the poms do the right thing :-)
> >
> > -Rahul
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [m2][PROPOSAL] Release process
Posted by Dennis Lundberg <de...@apache.org>.
If I raise my view and just look at the A, B, C and D headings, it
sounds good. But, there shouldn't be two options under B. IMO we should
always use the release plugin. That will give us consistent releases.
Should something be wrong with the release-plugin we'll be consistently
wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
in the long run.
Rahul Akolkar wrote:
> Based on couple of JIRA comments, it seems there still isn't consensus
> about a release process using m2 at Commons. I'll try to outline the
> process.
>
> <outline>
>
> [A] Release prep
>
> [B] Stage artifacts and site, to some location TBD (entire commands
> below, not abridged etc.):
>
> mvn -Prc release:prepare
> mvn -Prc release:perform
> mvn -Prc site-deploy
>
> Or, if you don't care about the release plugin, after setting final
> versions in [A]:
>
> mvn -Prc deploy
> mvn -Prc site-deploy
>
> [C] Vote
>
> [D] Go live
>
> mvn stage:copy ...
> mvn site-deploy
>
> </outline>
>
> Does this fit your mental model? If not, why not?
>
> Please keep the discussion at a "vision" level. Yes, the outline is
> flawed (all votes don't pass, there are loops etc.) Yes, required pom
> changes are not discussed. But, once process is OK'ed, we will make
> the poms do the right thing :-)
>
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org