[m2][PROPOSAL] Release process

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[m2][PROPOSAL] Release process

Rahul Akolkar
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Dennis Lundberg-2
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

James Carman
On 3/21/08, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Dennis Lundberg-2
James Carman wrote:

> On 3/21/08, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Rahul Akolkar
In reply to this post by Dennis Lundberg-2
On 3/21/08, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Rahul Akolkar
In reply to this post by James Carman
On 3/21/08, James Carman <[hidden email]> wrote:

> On 3/21/08, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

simon.kitching@chello.at
In reply to this post by Dennis Lundberg-2

On Sat, 2008-03-22 at 18:18 +0100, Dennis Lundberg wrote:

> James Carman wrote:
> > On 3/21/08, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Dennis Lundberg-2
In reply to this post by Rahul Akolkar
Rahul Akolkar wrote:

> On 3/21/08, Dennis Lundberg <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Dennis Lundberg-2
In reply to this post by simon.kitching@chello.at
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

James Carman
In reply to this post by simon.kitching@chello.at
On Sat, Mar 22, 2008 at 1:56 PM, simon <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Rahul Akolkar
In reply to this post by Dennis Lundberg-2
On 3/22/08, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Phil Steitz
In reply to this post by Rahul Akolkar
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

sebb-2-2
On 22/03/2008, Phil Steitz <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Niall Pemberton
In reply to this post by Phil Steitz
On Sat, Mar 22, 2008 at 10:10 PM, Phil Steitz <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Wendy Smoak
In reply to this post by Phil Steitz
On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Phil Steitz
On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <[hidden email]> wrote:

> On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Rahul Akolkar
In reply to this post by Niall Pemberton
On 3/22/08, Niall Pemberton <[hidden email]> wrote:
> On Sat, Mar 22, 2008 at 10:10 PM, Phil Steitz <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Rahul Akolkar
In reply to this post by Phil Steitz
On 3/22/08, Phil Steitz <[hidden email]> wrote:

> On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <[hidden email]> wrote:
>  > On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

Phil Steitz
>  > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2][PROPOSAL] Release process

James Carman
On Sun, Mar 23, 2008 at 2:23 AM, Phil Steitz <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12