You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by sebb <se...@gmail.com> on 2013/06/25 18:52:20 UTC
Release process updates
The mission of the ASF is to release software as source, and to ensure
that the released source is available under the Apache Licence.
Before a release can be approved it must be voted on by the PMC.
The review process needs to establish that the proposed source release
meets those aims.
It's all but impossible for reviewers to examine every single file in
a source archive to determine if it meets the criteria.
And it's not unknown for spurious files to creep into a release
(perhaps from a stale workspace - are releases always built from a
fresh checkout of the tag?)
However, PMCs are also required to check what is added to the SCM
(SVN/Git) to make sure it meets the required license criteria.
This is done on an ongoing basis as part of reviewing check-ins and
accepting new contributions.
So provided that all the files in the source release are also present
in SCM, the PMC can be reasonably sure that the source release meets
the ASF criteria.
Without having the SCM as a database of validated files, there are far
too many files in the average source archive to check individually.
And how would one check their provenance? The obvious way is to
compare them with the entries in SCM.
Therefore, I contend that a release vote does not make sense without
the SCM tag.
In the case of SVN, since tags are not immutable, the vote e-mail also
needs the revision.
Whether every reviewer actually checks the source archive against SCM
is another matter.
But if the required SCM information is not present, it would be
difficult to argue that the RM had provided sufficient information for
a valid review to take place.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 25 June 2013 19:33, Hervé BOUTEMY <he...@free.fr> wrote:
> Le mardi 25 juin 2013 17:52:20 sebb a écrit :
>> And it's not unknown for spurious files to creep into a release
>> (perhaps from a stale workspace - are releases always built from a
>> fresh checkout of the tag?)
> we use the release plugin, which does the release from a fresh checkout (FYI
> causing problems for people working in EU, since there is a delay between tag
> creation and content availability to subsequent checkout).
>
> I don't know any release from Maven project with unpredictable content: yes,
> such problem is unknown from Maven, because the release process tooling is
> consistent.
If reviewers aren't provided with the SVN tag to do the checks, of
course any such problems are likely to be unknown.
> Given this use of the release plugin, I don't see any problem with our release
> process (other than theory and over-generalization)
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 25 juin 2013 17:52:20 sebb a écrit :
> And it's not unknown for spurious files to creep into a release
> (perhaps from a stale workspace - are releases always built from a
> fresh checkout of the tag?)
we use the release plugin, which does the release from a fresh checkout (FYI
causing problems for people working in EU, since there is a delay between tag
creation and content availability to subsequent checkout).
I don't know any release from Maven project with unpredictable content: yes,
such problem is unknown from Maven, because the release process tooling is
consistent.
Given this use of the release plugin, I don't see any problem with our release
process (other than theory and over-generalization)
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
You havn't done this much have you?
mvn release:perform can be rerun and if you clean it the checkout will
always be into a clean location ./target/checkout/ by default.
On Wed, Jun 26, 2013 at 10:11 AM, sebb <se...@gmail.com> wrote:
> On 26 June 2013 00:34, Chris Graham <ch...@gmail.com> wrote:
> > This appears to be a variant of the "Do we reuse version numbers?"
> > discussion of recent times.
> > That was resolved.
> > Can we please not rehash this?
> >
> > -Chris
> >
> >
> > On Wed, Jun 26, 2013 at 2:52 AM, sebb <se...@gmail.com> wrote:
> >
> >> The mission of the ASF is to release software as source, and to ensure
> >> that the released source is available under the Apache Licence.
> >>
> >> Before a release can be approved it must be voted on by the PMC.
> >> The review process needs to establish that the proposed source release
> >> meets those aims.
> >>
> >> It's all but impossible for reviewers to examine every single file in
> >> a source archive to determine if it meets the criteria.
> >> And it's not unknown for spurious files to creep into a release
> >> (perhaps from a stale workspace - are releases always built from a
> >> fresh checkout of the tag?)
> >>
> >
> >
> > Ok, so you are not aware of the specifics of the maven release processes
> as
> > implemented by the release plugin.
> >
> > So you're asking a generic question.
> >
> > Here is how the release plugin works:
> >
> > release:prepare is the goal that performs some tests, changes to a non
> > snapshot version, creates the tag, bumps up the version no and commits
> the
> > changes to the pom.
> >
> > release:perform simply checks out the newly created tag, into a new
> > location (ie clean) and then calls "mvn deploy".
>
> And if the "mvn deploy" fails for any reason?
> Is it necessary to re-run release:perform?
> And does that always create a fresh workspace?
>
> > So for maven, yes, it is unknown for suprious files to creep in.
> >
> > -Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 01:43, Chris Graham <ch...@gmail.com> wrote:
> On Wed, Jun 26, 2013 at 10:36 AM, sebb <se...@gmail.com> wrote:
>
>> However there is also the possibility that vital files are missing
>> from the source archive.
>> For that to be detected, a comparison with the SVN tag is needed.
>>
>>
> How? Given the source archive is built from the checked out tag?
AIUI the source archive is build using the assembly descriptor; not
everything in the workspace is bundled into the archive.
> Please go and run some releases and you'll see how the process works.
>
> That way you will be able to ask some specific questions rather than some
> generic ones based upon a lack of understanding of the existing processes.
I am basing my responses on what has been said in this thread.
> -Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
On Wed, Jun 26, 2013 at 10:36 AM, sebb <se...@gmail.com> wrote:
> However there is also the possibility that vital files are missing
> from the source archive.
> For that to be detected, a comparison with the SVN tag is needed.
>
>
How? Given the source archive is built from the checked out tag?
Please go and run some releases and you'll see how the process works.
That way you will be able to ask some specific questions rather than some
generic ones based upon a lack of understanding of the existing processes.
-Chris
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 01:25, Barrie Treloar <ba...@gmail.com> wrote:
>> And if the "mvn deploy" fails for any reason?
>
> We get this often enough with a crappy connection to our nexus servers.
>
>> Is it necessary to re-run release:perform?
>
> release:perform may be at the stage where it has deleted the
> configuration file details, in which case you just revert to the
> manual steps that release:perform is automating for you.
Which could result in spurious files in the workspace.
People make mistakes.
> If its tagged everything correctly, and you build is fine - but the
> upload to the staging repository failed, then you can do this
> yourself.
If this route is taken, there is no guarantee that the workspace is clean.
People make mistakes.
> Or you can just re-spin the release process. No drama.
>
>> And does that always create a fresh workspace?
>
> Yes.
OK it might perhaps be possible to prove that this will never result
in additional spurious files appearing in source archives.
However there is also the possibility that vital files are missing
from the source archive.
For that to be detected, a comparison with the SVN tag is needed.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 02:59, Barrie Treloar <ba...@gmail.com> wrote:
>>> Then replace
>>> cd target/checkout && mvn clean deploy -Papache-release
>>> with
>>> delete target/checkout
>>> svn co <blah> to target/checkout
>>> mvn clean deploy -Papache-release
>>>
>>> Since it was mvn release:perform that created target/checkout in the
>>> first place and no one has made any changes in that directory, cd
>>
>> You cannot know that for sure.
>> People make mistakes; try things out, get distracted, forget that they
>> changed something.
>>
>>> target/checkout has the same results.
>>
>> Not guaranteed.
>
> In the end that does not matter.
>
> As long as the tag and the source release can be verified.
Which is why the revision is needed in the vote mail.
> See http://www.apache.org/dev/release.html#owned-controlled-hardware,
> which links to https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl
> as a helper script.
Yes, I often use that when reviewing releases to compare archives in
different formats (it's not unknown for those to disagree by more than
just EOL).
AFAIK at present the script cannot be used to compare SCM with source
archive, as there are files legitimately omitted from the source
release (e.g. doap).
In some cases there are additional generated files in the source
archive (e.g. DEPENDENCIES).
> The ASF release process does not help to ensure the release is useful,
> merely that it meets the legal obligations of the foundation.
Exactly my point.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Barrie Treloar <ba...@gmail.com>.
>> Then replace
>> cd target/checkout && mvn clean deploy -Papache-release
>> with
>> delete target/checkout
>> svn co <blah> to target/checkout
>> mvn clean deploy -Papache-release
>>
>> Since it was mvn release:perform that created target/checkout in the
>> first place and no one has made any changes in that directory, cd
>
> You cannot know that for sure.
> People make mistakes; try things out, get distracted, forget that they
> changed something.
>
>> target/checkout has the same results.
>
> Not guaranteed.
In the end that does not matter.
As long as the tag and the source release can be verified.
See http://www.apache.org/dev/release.html#owned-controlled-hardware,
which links to https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl
as a helper script.
The ASF release process does not help to ensure the release is useful,
merely that it meets the legal obligations of the foundation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 02:18, Barrie Treloar <ba...@gmail.com> wrote:
> On 26 June 2013 10:19, sebb <se...@gmail.com> wrote:
>> On 26 June 2013 01:41, Olivier Lamy <ol...@apache.org> wrote:
>>> correct.
>>> In case of failure during deploy:
>>> * cd target/checkout && mvn clean deploy -Papache-release
>>> or
>>> * export/checkout the tag && mvn clean deploy -Papache-release
>>
>> Neither of those guarantee that the workspace agrees with the tag.
>>
>> Only by checking out the tag into a fresh workspace can you hope to
>> guarantee that.
>
> Then replace
> cd target/checkout && mvn clean deploy -Papache-release
> with
> delete target/checkout
> svn co <blah> to target/checkout
> mvn clean deploy -Papache-release
>
> Since it was mvn release:perform that created target/checkout in the
> first place and no one has made any changes in that directory, cd
You cannot know that for sure.
People make mistakes; try things out, get distracted, forget that they
changed something.
> target/checkout has the same results.
Not guaranteed.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Barrie Treloar <ba...@gmail.com>.
On 26 June 2013 10:19, sebb <se...@gmail.com> wrote:
> On 26 June 2013 01:41, Olivier Lamy <ol...@apache.org> wrote:
>> correct.
>> In case of failure during deploy:
>> * cd target/checkout && mvn clean deploy -Papache-release
>> or
>> * export/checkout the tag && mvn clean deploy -Papache-release
>
> Neither of those guarantee that the workspace agrees with the tag.
>
> Only by checking out the tag into a fresh workspace can you hope to
> guarantee that.
Then replace
cd target/checkout && mvn clean deploy -Papache-release
with
delete target/checkout
svn co <blah> to target/checkout
mvn clean deploy -Papache-release
Since it was mvn release:perform that created target/checkout in the
first place and no one has made any changes in that directory, cd
target/checkout has the same results.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 01:41, Olivier Lamy <ol...@apache.org> wrote:
> correct.
> In case of failure during deploy:
> * cd target/checkout && mvn clean deploy -Papache-release
> or
> * export/checkout the tag && mvn clean deploy -Papache-release
Neither of those guarantee that the workspace agrees with the tag.
Only by checking out the tag into a fresh workspace can you hope to
guarantee that.
>
>
> 2013/6/26 Barrie Treloar <ba...@gmail.com>:
>>> And if the "mvn deploy" fails for any reason?
>>
>> We get this often enough with a crappy connection to our nexus servers.
>>
>>> Is it necessary to re-run release:perform?
>>
>> release:perform may be at the stage where it has deleted the
>> configuration file details, in which case you just revert to the
>> manual steps that release:perform is automating for you.
>>
>> If its tagged everything correctly, and you build is fine - but the
>> upload to the staging repository failed, then you can do this
>> yourself.
>>
>> Or you can just re-spin the release process. No drama.
>>
>>> And does that always create a fresh workspace?
>>
>> Yes.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Olivier Lamy <ol...@apache.org>.
correct.
In case of failure during deploy:
* cd target/checkout && mvn clean deploy -Papache-release
or
* export/checkout the tag && mvn clean deploy -Papache-release
2013/6/26 Barrie Treloar <ba...@gmail.com>:
>> And if the "mvn deploy" fails for any reason?
>
> We get this often enough with a crappy connection to our nexus servers.
>
>> Is it necessary to re-run release:perform?
>
> release:perform may be at the stage where it has deleted the
> configuration file details, in which case you just revert to the
> manual steps that release:perform is automating for you.
>
> If its tagged everything correctly, and you build is fine - but the
> upload to the staging repository failed, then you can do this
> yourself.
>
> Or you can just re-spin the release process. No drama.
>
>> And does that always create a fresh workspace?
>
> Yes.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Barrie Treloar <ba...@gmail.com>.
> And if the "mvn deploy" fails for any reason?
We get this often enough with a crappy connection to our nexus servers.
> Is it necessary to re-run release:perform?
release:perform may be at the stage where it has deleted the
configuration file details, in which case you just revert to the
manual steps that release:perform is automating for you.
If its tagged everything correctly, and you build is fine - but the
upload to the staging repository failed, then you can do this
yourself.
Or you can just re-spin the release process. No drama.
> And does that always create a fresh workspace?
Yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 00:34, Chris Graham <ch...@gmail.com> wrote:
> This appears to be a variant of the "Do we reuse version numbers?"
> discussion of recent times.
> That was resolved.
> Can we please not rehash this?
>
> -Chris
>
>
> On Wed, Jun 26, 2013 at 2:52 AM, sebb <se...@gmail.com> wrote:
>
>> The mission of the ASF is to release software as source, and to ensure
>> that the released source is available under the Apache Licence.
>>
>> Before a release can be approved it must be voted on by the PMC.
>> The review process needs to establish that the proposed source release
>> meets those aims.
>>
>> It's all but impossible for reviewers to examine every single file in
>> a source archive to determine if it meets the criteria.
>> And it's not unknown for spurious files to creep into a release
>> (perhaps from a stale workspace - are releases always built from a
>> fresh checkout of the tag?)
>>
>
>
> Ok, so you are not aware of the specifics of the maven release processes as
> implemented by the release plugin.
>
> So you're asking a generic question.
>
> Here is how the release plugin works:
>
> release:prepare is the goal that performs some tests, changes to a non
> snapshot version, creates the tag, bumps up the version no and commits the
> changes to the pom.
>
> release:perform simply checks out the newly created tag, into a new
> location (ie clean) and then calls "mvn deploy".
And if the "mvn deploy" fails for any reason?
Is it necessary to re-run release:perform?
And does that always create a fresh workspace?
> So for maven, yes, it is unknown for suprious files to creep in.
>
> -Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
This appears to be a variant of the "Do we reuse version numbers?"
discussion of recent times.
That was resolved.
Can we please not rehash this?
-Chris
On Wed, Jun 26, 2013 at 2:52 AM, sebb <se...@gmail.com> wrote:
> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
> And it's not unknown for spurious files to creep into a release
> (perhaps from a stale workspace - are releases always built from a
> fresh checkout of the tag?)
>
Ok, so you are not aware of the specifics of the maven release processes as
implemented by the release plugin.
So you're asking a generic question.
Here is how the release plugin works:
release:prepare is the goal that performs some tests, changes to a non
snapshot version, creates the tag, bumps up the version no and commits the
changes to the pom.
release:perform simply checks out the newly created tag, into a new
location (ie clean) and then calls "mvn deploy".
So for maven, yes, it is unknown for suprious files to creep in.
-Chris
Re: Release process updates
Posted by Fred Cooke <fr...@gmail.com>.
Especially in other environments where it's used properly, by its own
principals! :-p
On Tue, Jun 25, 2013 at 9:43 PM, Hervé BOUTEMY <he...@free.fr>wrote:
> Le mardi 25 juin 2013 21:15:11 Uwe Schindler a écrit :
> > This is a slightly different
> > workflow, but is proven to work since years now.
> great workflow
>
> here, at maven project, we use release plugin: this is a slightly different
> workflow, but is proven to work since years now.
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 25 juin 2013 21:15:11 Uwe Schindler a écrit :
> This is a slightly different
> workflow, but is proven to work since years now.
great workflow
here, at maven project, we use release plugin: this is a slightly different
workflow, but is proven to work since years now.
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Fred Cooke <fr...@gmail.com>.
I very much prefer your method, Uwe! There are lots of ways to do this
"right". I hope one of those is chosen.
On Tue, Jun 25, 2013 at 9:15 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> I agree with sebb. I am not a Maven committer, but the release revision is
> very important in the Lucene Project (where I am the chair).
> We have another workflow, working with revision number:
> - Release manager produces source and binary artifacts from a checkout of
> the current development brank (trunk aka 5.x or stable aka 4.x), publishes
> them on people.apache.org in a folder named
> http://people.apache.org/~use/staging-area/lucene-solr-X.Y-r1234567
> - Release manager does *not* create an SVN tag at that time!!! The vote is
> on the revision and artifacts only!
> - We have automated release testing (we check for spurious files in the
> archives by our python-based "smoke tester"). This checks things like all
> JARs have correct META-INF, no license files are missing, NOTICE files are
> referring to *all* external dependencies, LICENSE.txt is in root folder of
> TGZ, line feeds are unix-only, release binary was compiled with the
> *minimum* JDK version (what we use as -source/-target for javac), and so on.
> - Once vote passes, release manager tags the exact revision number as used
> above in the folder name (svn cp -r1234567 ...) and releases the artifacts.
>
> By that there is no need to recreate tags, because the tag is only created
> when the stuff was actually released. This is a slightly different
> workflow, but is proven to work since years now.
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: sebb [mailto:sebbaz@gmail.com]
> > Sent: Tuesday, June 25, 2013 6:52 PM
> > To: dev@maven.apache.org
> > Subject: Release process updates
> >
> > The mission of the ASF is to release software as source, and to ensure
> that
> > the released source is available under the Apache Licence.
> >
> > Before a release can be approved it must be voted on by the PMC.
> > The review process needs to establish that the proposed source release
> > meets those aims.
> >
> > It's all but impossible for reviewers to examine every single file in a
> source
> > archive to determine if it meets the criteria.
> > And it's not unknown for spurious files to creep into a release (perhaps
> from
> > a stale workspace - are releases always built from a fresh checkout of
> the
> > tag?)
> >
> > However, PMCs are also required to check what is added to the SCM
> > (SVN/Git) to make sure it meets the required license criteria.
> > This is done on an ongoing basis as part of reviewing check-ins and
> accepting
> > new contributions.
> > So provided that all the files in the source release are also present in
> SCM,
> > the PMC can be reasonably sure that the source release meets the ASF
> > criteria.
> >
> > Without having the SCM as a database of validated files, there are far
> too
> > many files in the average source archive to check individually.
> > And how would one check their provenance? The obvious way is to compare
> > them with the entries in SCM.
> >
> > Therefore, I contend that a release vote does not make sense without the
> > SCM tag.
> > In the case of SVN, since tags are not immutable, the vote e-mail also
> needs
> > the revision.
> >
> > Whether every reviewer actually checks the source archive against SCM is
> > another matter.
> > But if the required SCM information is not present, it would be
> difficult to
> > argue that the RM had provided sufficient information for a valid review
> to
> > take place.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> > commands, e-mail: dev-help@maven.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 25 June 2013 20:15, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> I agree with sebb. I am not a Maven committer, but the release revision is very important in the Lucene Project (where I am the chair).
> We have another workflow, working with revision number:
> - Release manager produces source and binary artifacts from a checkout of the current development brank (trunk aka 5.x or stable aka 4.x), publishes them on people.apache.org in a folder named http://people.apache.org/~use/staging-area/lucene-solr-X.Y-r1234567
> - Release manager does *not* create an SVN tag at that time!!! The vote is on the revision and artifacts only!
> - We have automated release testing (we check for spurious files in the archives by our python-based "smoke tester"). This checks things like all JARs have correct META-INF, no license files are missing, NOTICE files are referring to *all* external dependencies, LICENSE.txt is in root folder of TGZ, line feeds are unix-only, release binary was compiled with the *minimum* JDK version (what we use as -source/-target for javac), and so on.
> - Once vote passes, release manager tags the exact revision number as used above in the folder name (svn cp -r1234567 ...) and releases the artifacts.
>
> By that there is no need to recreate tags, because the tag is only created when the stuff was actually released. This is a slightly different workflow, but is proven to work since years now.
Since the release process uses the revision number, it does not
particularly matter that the code is still in trunk; after all trunk
and tags are just names.
I find it easier to work with a named tag (perhaps because I am used
to it), but so long as the SVN source is uniquely identified and used
to compare against the source contents it does not matter what the
name is.
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Tuesday, June 25, 2013 6:52 PM
>> To: dev@maven.apache.org
>> Subject: Release process updates
>>
>> The mission of the ASF is to release software as source, and to ensure that
>> the released source is available under the Apache Licence.
>>
>> Before a release can be approved it must be voted on by the PMC.
>> The review process needs to establish that the proposed source release
>> meets those aims.
>>
>> It's all but impossible for reviewers to examine every single file in a source
>> archive to determine if it meets the criteria.
>> And it's not unknown for spurious files to creep into a release (perhaps from
>> a stale workspace - are releases always built from a fresh checkout of the
>> tag?)
>>
>> However, PMCs are also required to check what is added to the SCM
>> (SVN/Git) to make sure it meets the required license criteria.
>> This is done on an ongoing basis as part of reviewing check-ins and accepting
>> new contributions.
>> So provided that all the files in the source release are also present in SCM,
>> the PMC can be reasonably sure that the source release meets the ASF
>> criteria.
>>
>> Without having the SCM as a database of validated files, there are far too
>> many files in the average source archive to check individually.
>> And how would one check their provenance? The obvious way is to compare
>> them with the entries in SCM.
>>
>> Therefore, I contend that a release vote does not make sense without the
>> SCM tag.
>> In the case of SVN, since tags are not immutable, the vote e-mail also needs
>> the revision.
>>
>> Whether every reviewer actually checks the source archive against SCM is
>> another matter.
>> But if the required SCM information is not present, it would be difficult to
>> argue that the RM had provided sufficient information for a valid review to
>> take place.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
>> commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Release process updates
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
I agree with sebb. I am not a Maven committer, but the release revision is very important in the Lucene Project (where I am the chair).
We have another workflow, working with revision number:
- Release manager produces source and binary artifacts from a checkout of the current development brank (trunk aka 5.x or stable aka 4.x), publishes them on people.apache.org in a folder named http://people.apache.org/~use/staging-area/lucene-solr-X.Y-r1234567
- Release manager does *not* create an SVN tag at that time!!! The vote is on the revision and artifacts only!
- We have automated release testing (we check for spurious files in the archives by our python-based "smoke tester"). This checks things like all JARs have correct META-INF, no license files are missing, NOTICE files are referring to *all* external dependencies, LICENSE.txt is in root folder of TGZ, line feeds are unix-only, release binary was compiled with the *minimum* JDK version (what we use as -source/-target for javac), and so on.
- Once vote passes, release manager tags the exact revision number as used above in the folder name (svn cp -r1234567 ...) and releases the artifacts.
By that there is no need to recreate tags, because the tag is only created when the stuff was actually released. This is a slightly different workflow, but is proven to work since years now.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, June 25, 2013 6:52 PM
> To: dev@maven.apache.org
> Subject: Release process updates
>
> The mission of the ASF is to release software as source, and to ensure that
> the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in a source
> archive to determine if it meets the criteria.
> And it's not unknown for spurious files to creep into a release (perhaps from
> a stale workspace - are releases always built from a fresh checkout of the
> tag?)
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and accepting
> new contributions.
> So provided that all the files in the source release are also present in SCM,
> the PMC can be reasonably sure that the source release meets the ASF
> criteria.
>
> Without having the SCM as a database of validated files, there are far too
> many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to compare
> them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without the
> SCM tag.
> In the case of SVN, since tags are not immutable, the vote e-mail also needs
> the revision.
>
> Whether every reviewer actually checks the source archive against SCM is
> another matter.
> But if the required SCM information is not present, it would be difficult to
> argue that the RM had provided sufficient information for a valid review to
> take place.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 1 July 2013 08:17, Andreas Gudian <an...@gmail.com> wrote:
>> 2013/6/26 sebb <sebbaz@gmail.com <javascript:;>>:
>> > The mission of the ASF is to release software as source, and to ensure
>> > that the released source is available under the Apache Licence.
>>
>> Excuse me but I have always understand the ASF mission as building
>> communities around softwares.
>> Community over Code and not Process over Code.
>>
>> I believe (my personal opinion) we are here to make two communities
>> happy: dev community with easing their task to build and release good
>> software for the users community.
The software is not good if it is found to contain source code that
should not be there.
>>
>> With all of those emails, it's just a way to discourage people who
>> want to release software for their users.
I had no intention (or idea) that my simple request to add the URL and
revision to e-mails would create such a storm of resistance.
>> Yes too much (non useful) process tend/will discourage volunteers to
>> release something.
The change in process is minimal; a lot less work than even a single
reply to this thread.
>> My 0,02AUD
>> --
>> Olivier
>>
>
> +1, Oliver.
>
> Sure we need some kind of a legal basis and yes, we want to deliver as high
> a quality it is feasible for us. But in the end we're here to have fun
> coding stuff that makes a difference for the users.
> That means: keep the processes lean, as well as the discussion on
> improvements to the processes.
>
> Those were my 0,02€.
>
> Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Andreas Gudian <an...@gmail.com>.
> 2013/6/26 sebb <sebbaz@gmail.com <javascript:;>>:
> > The mission of the ASF is to release software as source, and to ensure
> > that the released source is available under the Apache Licence.
>
> Excuse me but I have always understand the ASF mission as building
> communities around softwares.
> Community over Code and not Process over Code.
>
> I believe (my personal opinion) we are here to make two communities
> happy: dev community with easing their task to build and release good
> software for the users community.
>
> With all of those emails, it's just a way to discourage people who
> want to release software for their users.
> Yes too much (non useful) process tend/will discourage volunteers to
> release something.
>
> My 0,02AUD
> --
> Olivier
>
+1, Oliver.
Sure we need some kind of a legal basis and yes, we want to deliver as high
a quality it is feasible for us. But in the end we're here to have fun
coding stuff that makes a difference for the users.
That means: keep the processes lean, as well as the discussion on
improvements to the processes.
Those were my 0,02€.
Andreas
Re: Release process updates
Posted by Olivier Lamy <ol...@apache.org>.
2013/6/26 sebb <se...@gmail.com>:
> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
Excuse me but I have always understand the ASF mission as building
communities around softwares.
Community over Code and not Process over Code.
I believe (my personal opinion) we are here to make two communities
happy: dev community with easing their task to build and release good
software for the users community.
With all of those emails, it's just a way to discourage people who
want to release software for their users.
Yes too much (non useful) process tend/will discourage volunteers to
release something.
My 0,02AUD
--
Olivier
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
> And it's not unknown for spurious files to creep into a release
> (perhaps from a stale workspace - are releases always built from a
> fresh checkout of the tag?)
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> the SCM tag.
> In the case of SVN, since tags are not immutable, the vote e-mail also
> needs the revision.
>
> Whether every reviewer actually checks the source archive against SCM
> is another matter.
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a valid review to take place.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 25 June 2013 19:19, Ralph Goers <ra...@dslextreme.com> wrote:
> Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient.
The only way to know which version of the tag is relevant is to work
out which tag happened to be present when the vote took place.
Since SVN tags are not physically immutable, they must be identified
with the revision.
Why make a fuss over providing the info - which is readily available
to the RM from the commit message - when it makes it so much easier in
retrospect to know what was voted on.
Also if there are several versions of a tag and vote threads - as
happens frequently - it can be very difficult untangling which is
which, as they can easily overlap in time if people have not caught up
fully with their e-mail.
It needs to be absolutely clear what reviewers are voting on, both at
the time, and later on when memories have faded.
> Ralph
>
>
> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>
>> Not really, no. The developer may have re-spun it again and be about to
>> email again. You have no idea what you're looking at unless you know the
>> revision. SVN will die off within a decade and this discussion will become
>> critical. Better to figure out how to support proper techniques now, rather
>> than wait until forced to.
>>
>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>
>>> I disagree that the revision is required. I know that the RM is going to
>>> recreate the tag with each release candidate. Therefore, so long as I
>>> refetch that tag for every release vote I can be confident that I am
>>> reviewing the release contents.
>>>
>>> Ralph
>>>
>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>
>>>> The mission of the ASF is to release software as source, and to ensure
>>>> that the released source is available under the Apache Licence.
>>>>
>>>> Before a release can be approved it must be voted on by the PMC.
>>>> The review process needs to establish that the proposed source release
>>>> meets those aims.
>>>>
>>>> It's all but impossible for reviewers to examine every single file in
>>>> a source archive to determine if it meets the criteria.
>>>> And it's not unknown for spurious files to creep into a release
>>>> (perhaps from a stale workspace - are releases always built from a
>>>> fresh checkout of the tag?)
>>>>
>>>> However, PMCs are also required to check what is added to the SCM
>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>> accepting new contributions.
>>>> So provided that all the files in the source release are also present
>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>> the ASF criteria.
>>>>
>>>> Without having the SCM as a database of validated files, there are far
>>>> too many files in the average source archive to check individually.
>>>> And how would one check their provenance? The obvious way is to
>>>> compare them with the entries in SCM.
>>>>
>>>> Therefore, I contend that a release vote does not make sense without
>>>> the SCM tag.
>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>> needs the revision.
>>>>
>>>> Whether every reviewer actually checks the source archive against SCM
>>>> is another matter.
>>>> But if the required SCM information is not present, it would be
>>>> difficult to argue that the RM had provided sufficient information for
>>>> a valid review to take place.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Hervé BOUTEMY <he...@free.fr>.
+1
easy to use, very powerful, and produces artifacts consistent with scm
and for those who didn't read the doc: prepare [1] and perform [2]
[1] http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
[2] http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
Le mercredi 26 juin 2013 09:20:40 Olivier Lamy a écrit :
> 2013/6/26 sebb <se...@gmail.com>:
> > It would be a lot better to use RC1 RC2 etc initially, and copy the
> > successful tag to the GA tag.
>
> this mean modifying manually the pom to change version (from 1.0-RC1
> to 1.0) before copying teh RC tag, changing the scm information etc...
> Rebuild jars ? because if you change the pom it means you change the
> sources so need an other build/vote..
>
> Frankly currently we have a very simple process which works very fine:
> * mvn clean release:prepare release:perform -B (-Dusername= -Dpassword=)
> * verifying staging repo
> * closing the staging repo
> * cd target/checkout && mvn clean site-deploy
> * and that's it
>
> Perso, I don't want we move to something over complicated without any
> real added value.
>
> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
> >> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed
> >> release vote instead of deleting them.>>
> >> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers
<ra...@dslextreme.com>wrote:
> >>>> Again I have to disagree. The release manager will send an email
> >>>> closing
> >>>> the prior release. At this point all the prior release artifacts are
> >>>> junk
> >>>> even if they still exist. At some point the release manager will
> >>>> delete
> >>>> the tag and rerun the release.
> >>>
> >>> That's a no-no IMO. Tags that have been voted on should never be
> >>> deleted.
> >>>
> >>> Gary
> >>>
> >>>> At this point the tag is still junk to everyone else because they have
> >>>> no
> >>>> idea what the RM is doing - so they shouldn't be making assumptions
> >>>> about
> >>>> non-released tags. Once he sends the email though the tag will be
> >>>> valid.
> >>>> Sure having the revision number helps but unless the RM completely
> >>>> screws
> >>>> up the tag should be sufficient.
> >>>>
> >>>> Ralph
> >>>>
> >>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >>>>> Not really, no. The developer may have re-spun it again and be about
> >>>>> to
> >>>>> email again. You have no idea what you're looking at unless you know
> >>>>> the
> >>>>> revision. SVN will die off within a decade and this discussion will
> >>>>
> >>>> become
> >>>>
> >>>>> critical. Better to figure out how to support proper techniques now,
> >>>>
> >>>> rather
> >>>>
> >>>>> than wait until forced to.
> >>>>>
> >>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers
> >>>>> <ralph.goers@dslextreme.com
> >>>>>
> >>>>> wrote:
> >>>>>> I disagree that the revision is required. I know that the RM is
> >>>>>> going
> >>>>
> >>>> to
> >>>>
> >>>>>> recreate the tag with each release candidate. Therefore, so long as
> >>>>>> I
> >>>>>> refetch that tag for every release vote I can be confident that I am
> >>>>>> reviewing the release contents.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >>>>>>> The mission of the ASF is to release software as source, and to
> >>>>>>> ensure
> >>>>>>> that the released source is available under the Apache Licence.
> >>>>>>>
> >>>>>>> Before a release can be approved it must be voted on by the PMC.
> >>>>>>> The review process needs to establish that the proposed source
> >>>>>>> release
> >>>>>>> meets those aims.
> >>>>>>>
> >>>>>>> It's all but impossible for reviewers to examine every single file
> >>>>>>> in
> >>>>>>> a source archive to determine if it meets the criteria.
> >>>>>>> And it's not unknown for spurious files to creep into a release
> >>>>>>> (perhaps from a stale workspace - are releases always built from a
> >>>>>>> fresh checkout of the tag?)
> >>>>>>>
> >>>>>>> However, PMCs are also required to check what is added to the SCM
> >>>>>>> (SVN/Git) to make sure it meets the required license criteria.
> >>>>>>> This is done on an ongoing basis as part of reviewing check-ins and
> >>>>>>> accepting new contributions.
> >>>>>>> So provided that all the files in the source release are also
> >>>>>>> present
> >>>>>>> in SCM, the PMC can be reasonably sure that the source release meets
> >>>>>>> the ASF criteria.
> >>>>>>>
> >>>>>>> Without having the SCM as a database of validated files, there are
> >>>>>>> far
> >>>>>>> too many files in the average source archive to check individually.
> >>>>>>> And how would one check their provenance? The obvious way is to
> >>>>>>> compare them with the entries in SCM.
> >>>>>>>
> >>>>>>> Therefore, I contend that a release vote does not make sense without
> >>>>>>> the SCM tag.
> >>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
> >>>>>>> also
> >>>>>>> needs the revision.
> >>>>>>>
> >>>>>>> Whether every reviewer actually checks the source archive against
> >>>>>>> SCM
> >>>>>>> is another matter.
> >>>>>>> But if the required SCM information is not present, it would be
> >>>>>>> difficult to argue that the RM had provided sufficient information
> >>>>>>> for
> >>>>>>> a valid review to take place.
> >>>>>>>
> >>>>>>> --------------------------------------------------------------------
> >>>>>>> -
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> Java Persistence with Hibernate, Second
> >>> Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition
> >>> <http://www.manning.com/tahchiev/> Spring Batch in Action
> >>> <http://www.manning.com/templier/>
> >>> Blog: http://garygregory.wordpress.com
> >>> Home: http://garygregory.com/
> >>> Tweet! http://twitter.com/GaryGregory
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
Yes, tags are cheap so can be kept until no longer useful.
If there are a lot of stale tags it can get difficult to navigate the
tags directory, so it makes sense to delete all but the successful tag
once the vote has completed.
There should be no need to keep failed tags once the vote is complete.
That's what we tend to do on Commons and HttpComponents, except that
the tags are immutable.
We call them RC1, RC2 etc initially and copy (sometimes rename) to the
GA tag on release.
On 27 June 2013 01:35, Olivier Lamy <ol...@apache.org> wrote:
> Sounds a good idea for me (probably until someone else complain :-) ).
> And if that stop discussions and move people to working on code/fixing
> issues (i.e something very important for users) that will be great!
>
>
> 2013/6/27 Mirko Friedenhagen <mf...@gmail.com>:
>> Hello there,
>>
>> when. respinning a release it would of help IMO instead of deleting the tag
>> to rename it to e.g. maven-javadoc-plugin-2.9-rc1 using "svn mv".
>>
>> By means of this you are able to easily diff between e.g. released 2.8 and
>> the final 2.9 as well as between 2.9-rc1 and the final 2.9.
>>
>> Regards Mirko
>> --
>> Sent from my mobile
>> On Jun 26, 2013 12:14 PM, "sebb" <se...@gmail.com> wrote:
>>
>>> On 26 June 2013 10:56, Chris Graham <ch...@gmail.com> wrote:
>>> > On Wed, Jun 26, 2013 at 7:06 PM, sebb <se...@gmail.com> wrote:
>>> >
>>> >> I meant: if the pom is created with the correct final URLs in the
>>> >> first place, it won't have to be changed.
>>> >>
>>> >>
>>> > They are. If you'd used the release plugin, then you would have seen
>>> this.
>>> >
>>>
>>> I was responding to this:
>>>
>>> >>>
>>> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
>>> > -1
>>> > Except then the poms will point to the wrong place.
>>> <<<
>>>
>>> but maybe I misunderstood.
>>>
>>> >
>>> >> It might need a tweak to the appropriate plugin, but it's not
>>> >> impossible to achieve.
>>> >>
>>> >
>>> > You've not clearly stated what it is that you actually intend to achieve.
>>>
>>> I thought I stated that clearly in my original post at the start of this
>>> thread.
>>>
>>> >
>>> >> The same process would work with the system used by Lucene.
>>> >>
>>> >> No, it wouldn't. From my reading of that email, there appeared to be far
>>> > more manual steps involved, and probably a far larger time window
>>> involved
>>> > as well. But I'd have to grok it a little more to be sure.
>>> >
>>> >
>>> >>
>>> >>
>>> > On 26 June 2013 06:48, Hervé BOUTEMY <he...@free.fr> wrote:
>>> >> > the jar content isn't updated: so you have jar artifacts inconsistent
>>> >> with svn
>>> >> >
>>> >> > Le mercredi 26 juin 2013 01:08:59 sebb a écrit :
>>> >> >> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
>>> >> >> > -1
>>> >> >> > Except then the poms will point to the wrong place.
>>> >> >>
>>> >> >> Depends how the poms are updated.
>>> >> >>
>>> >> >> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory
>>> >> > <ga...@gmail.com>wrote:
>>> >> >> >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
>>> >> >> >> > It would be a lot better to use RC1 RC2 etc initially, and copy
>>> the
>>> >> >> >> > successful tag to the GA tag.
>>> >> >> >>
>>> >> >> >> +1 ! :)
>>> >> >> >>
>>> >> >> >> Gary
>>> >> >> >>
>>> >> >> >> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>>> >> wrote:
>>> >> >> >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc
>>> after a
>>> >> >> >>
>>> >> >> >> failed
>>> >> >> >>
>>> >> >> >> > release vote instead of deleting them.
>>> >> >> >> >
>>> >> >> >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>> >> >> >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>>> >> >> >> >
>>> >> >> >> > ralph.goers@dslextreme.com>wrote:
>>> >> >> >> > >>> Again I have to disagree. The release manager will send an
>>> >> email
>>> >> >> >> >
>>> >> >> >> > closing
>>> >> >> >> >
>>> >> >> >> > >>> the prior release. At this point all the prior release
>>> >> artifacts
>>> >> >> >> > >>> are
>>> >> >> >> >
>>> >> >> >> > junk
>>> >> >> >> >
>>> >> >> >> > >>> even if they still exist. At some point the release manager
>>> >> will
>>> >> >> >> >
>>> >> >> >> > delete
>>> >> >> >> >
>>> >> >> >> > >>> the tag and rerun the release.
>>> >> >> >> > >>
>>> >> >> >> > >> That's a no-no IMO. Tags that have been voted on should
>>> never be
>>> >> >> >> >
>>> >> >> >> > deleted.
>>> >> >> >> >
>>> >> >> >> > >> Gary
>>> >> >> >> > >>
>>> >> >> >> > >>> At this point the tag is still junk to everyone else because
>>> >> they
>>> >> >> >>
>>> >> >> >> have
>>> >> >> >>
>>> >> >> >> > no
>>> >> >> >> >
>>> >> >> >> > >>> idea what the RM is doing - so they shouldn't be making
>>> >> assumptions
>>> >> >> >> >
>>> >> >> >> > about
>>> >> >> >> >
>>> >> >> >> > >>> non-released tags. Once he sends the email though the tag
>>> >> will be
>>> >> >> >> >
>>> >> >> >> > valid.
>>> >> >> >> >
>>> >> >> >> > >>> Sure having the revision number helps but unless the RM
>>> >> completely
>>> >> >> >> >
>>> >> >> >> > screws
>>> >> >> >> >
>>> >> >> >> > >>> up the tag should be sufficient.
>>> >> >> >> > >>>
>>> >> >> >> > >>> Ralph
>>> >> >> >> > >>>
>>> >> >> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>> >> >> >> > >>>> Not really, no. The developer may have re-spun it again
>>> and be
>>> >> >> >> > >>>> about
>>> >> >> >> >
>>> >> >> >> > to
>>> >> >> >> >
>>> >> >> >> > >>>> email again. You have no idea what you're looking at unless
>>> >> you
>>> >> >> >> > >>>> know
>>> >> >> >> >
>>> >> >> >> > the
>>> >> >> >> >
>>> >> >> >> > >>>> revision. SVN will die off within a decade and this
>>> discussion
>>> >> >> >> > >>>> will
>>> >> >> >> > >>>
>>> >> >> >> > >>> become
>>> >> >> >> > >>>
>>> >> >> >> > >>>> critical. Better to figure out how to support proper
>>> >> techniques
>>> >> >> >> > >>>> now,
>>> >> >> >> > >>>
>>> >> >> >> > >>> rather
>>> >> >> >> > >>>
>>> >> >> >> > >>>> than wait until forced to.
>>> >> >> >> > >>>>
>>> >> >> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>>> >> >> >> >
>>> >> >> >> > ralph.goers@dslextreme.com
>>> >> >> >> >
>>> >> >> >> > >>>> wrote:
>>> >> >> >> > >>>>> I disagree that the revision is required. I know that the
>>> >> RM is
>>> >> >> >> >
>>> >> >> >> > going
>>> >> >> >> >
>>> >> >> >> > >>> to
>>> >> >> >> > >>>
>>> >> >> >> > >>>>> recreate the tag with each release candidate. Therefore,
>>> so
>>> >> long
>>> >> >> >>
>>> >> >> >> as
>>> >> >> >>
>>> >> >> >> > I
>>> >> >> >> >
>>> >> >> >> > >>>>> refetch that tag for every release vote I can be confident
>>> >> that I
>>> >> >> >>
>>> >> >> >> am
>>> >> >> >>
>>> >> >> >> > >>>>> reviewing the release contents.
>>> >> >> >> > >>>>>
>>> >> >> >> > >>>>> Ralph
>>> >> >> >> > >>>>>
>>> >> >> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>> >> >> >> > >>>>>> The mission of the ASF is to release software as source,
>>> >> and to
>>> >> >> >> >
>>> >> >> >> > ensure
>>> >> >> >> >
>>> >> >> >> > >>>>>> that the released source is available under the Apache
>>> >> Licence.
>>> >> >> >> > >>>>>>
>>> >> >> >> > >>>>>> Before a release can be approved it must be voted on by
>>> the
>>> >> PMC.
>>> >> >> >> > >>>>>> The review process needs to establish that the proposed
>>> >> source
>>> >> >> >> >
>>> >> >> >> > release
>>> >> >> >> >
>>> >> >> >> > >>>>>> meets those aims.
>>> >> >> >> > >>>>>>
>>> >> >> >> > >>>>>> It's all but impossible for reviewers to examine every
>>> >> single
>>> >> >> >> > >>>>>> file
>>> >> >> >> >
>>> >> >> >> > in
>>> >> >> >> >
>>> >> >> >> > >>>>>> a source archive to determine if it meets the criteria.
>>> >> >> >> > >>>>>> And it's not unknown for spurious files to creep into a
>>> >> release
>>> >> >> >> > >>>>>> (perhaps from a stale workspace - are releases always
>>> built
>>> >> from
>>> >> >> >> > >>>>>> a
>>> >> >> >> > >>>>>> fresh checkout of the tag?)
>>> >> >> >> > >>>>>>
>>> >> >> >> > >>>>>> However, PMCs are also required to check what is added to
>>> >> the
>>> >> >> >> > >>>>>> SCM
>>> >> >> >> > >>>>>> (SVN/Git) to make sure it meets the required license
>>> >> criteria.
>>> >> >> >> > >>>>>> This is done on an ongoing basis as part of reviewing
>>> >> check-ins
>>> >> >> >>
>>> >> >> >> and
>>> >> >> >>
>>> >> >> >> > >>>>>> accepting new contributions.
>>> >> >> >> > >>>>>> So provided that all the files in the source release are
>>> >> also
>>> >> >> >> >
>>> >> >> >> > present
>>> >> >> >> >
>>> >> >> >> > >>>>>> in SCM, the PMC can be reasonably sure that the source
>>> >> release
>>> >> >> >>
>>> >> >> >> meets
>>> >> >> >>
>>> >> >> >> > >>>>>> the ASF criteria.
>>> >> >> >> > >>>>>>
>>> >> >> >> > >>>>>> Without having the SCM as a database of validated files,
>>> >> there
>>> >> >> >> > >>>>>> are
>>> >> >> >> >
>>> >> >> >> > far
>>> >> >> >> >
>>> >> >> >> > >>>>>> too many files in the average source archive to check
>>> >> >> >>
>>> >> >> >> individually.
>>> >> >> >>
>>> >> >> >> > >>>>>> And how would one check their provenance? The obvious way
>>> >> is to
>>> >> >> >> > >>>>>> compare them with the entries in SCM.
>>> >> >> >> > >>>>>>
>>> >> >> >> > >>>>>> Therefore, I contend that a release vote does not make
>>> sense
>>> >> >> >>
>>> >> >> >> without
>>> >> >> >>
>>> >> >> >> > >>>>>> the SCM tag.
>>> >> >> >> > >>>>>> In the case of SVN, since tags are not immutable, the
>>> vote
>>> >> >> >> > >>>>>> e-mail
>>> >> >> >> >
>>> >> >> >> > also
>>> >> >> >> >
>>> >> >> >> > >>>>>> needs the revision.
>>> >> >> >> > >>>>>>
>>> >> >> >> > >>>>>> Whether every reviewer actually checks the source archive
>>> >> >> >> > >>>>>> against
>>> >> >> >> >
>>> >> >> >> > SCM
>>> >> >> >> >
>>> >> >> >> > >>>>>> is another matter.
>>> >> >> >> > >>>>>> But if the required SCM information is not present, it
>>> >> would be
>>> >> >> >> > >>>>>> difficult to argue that the RM had provided sufficient
>>> >> >> >> > >>>>>> information
>>> >> >> >> >
>>> >> >> >> > for
>>> >> >> >> >
>>> >> >> >> > >>>>>> a valid review to take place.
>>> >> >> >> >
>>> >> >> >> >
>>> >> ---------------------------------------------------------------------
>>> >> >> >> >
>>> >> >> >> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> >> >> > >>>>>> For additional commands, e-mail:
>>> dev-help@maven.apache.org
>>> >> >> >>
>>> >> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> >>
>>> >> >> >> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> >> >> > >>>>> For additional commands, e-mail:
>>> dev-help@maven.apache.org
>>> >> >> >> > >>>
>>> >> >> >> > >>>
>>> >> -------------------------------------------------------------------
>>> >> >> >> > >>> --
>>> >> >> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> >> >> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>>> >> >> >> > >>
>>> >> >> >> > >> --
>>> >> >> >> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> >> >> >> > >> Java Persistence with Hibernate, Second Edition<
>>> >> >> >> >
>>> >> >> >> > http://www.manning.com/bauer3/>
>>> >> >> >> >
>>> >> >> >> > >> JUnit in Action, Second Edition <
>>> >> http://www.manning.com/tahchiev/>
>>> >> >> >> > >> Spring Batch in Action <http://www.manning.com/templier/>
>>> >> >> >> > >> Blog: http://garygregory.wordpress.com
>>> >> >> >> > >> Home: http://garygregory.com/
>>> >> >> >> > >> Tweet! http://twitter.com/GaryGregory
>>> >> >> >> > >
>>> >> >> >> > >
>>> >> ---------------------------------------------------------------------
>>> >> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>>> >> >> >> >
>>> >> >> >> >
>>> >> ---------------------------------------------------------------------
>>> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> >> >> >> Java Persistence with Hibernate, Second Edition<
>>> >> >> >> http://www.manning.com/bauer3/>
>>> >> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
>>> >
>>> >> >> >> Spring Batch in Action <http://www.manning.com/templier/>
>>> >> >> >> Blog: http://garygregory.wordpress.com
>>> >> >> >> Home: http://garygregory.com/
>>> >> >> >> Tweet! http://twitter.com/GaryGregory
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Olivier Lamy <ol...@apache.org>.
Sounds a good idea for me (probably until someone else complain :-) ).
And if that stop discussions and move people to working on code/fixing
issues (i.e something very important for users) that will be great!
2013/6/27 Mirko Friedenhagen <mf...@gmail.com>:
> Hello there,
>
> when. respinning a release it would of help IMO instead of deleting the tag
> to rename it to e.g. maven-javadoc-plugin-2.9-rc1 using "svn mv".
>
> By means of this you are able to easily diff between e.g. released 2.8 and
> the final 2.9 as well as between 2.9-rc1 and the final 2.9.
>
> Regards Mirko
> --
> Sent from my mobile
> On Jun 26, 2013 12:14 PM, "sebb" <se...@gmail.com> wrote:
>
>> On 26 June 2013 10:56, Chris Graham <ch...@gmail.com> wrote:
>> > On Wed, Jun 26, 2013 at 7:06 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> I meant: if the pom is created with the correct final URLs in the
>> >> first place, it won't have to be changed.
>> >>
>> >>
>> > They are. If you'd used the release plugin, then you would have seen
>> this.
>> >
>>
>> I was responding to this:
>>
>> >>>
>> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
>> > -1
>> > Except then the poms will point to the wrong place.
>> <<<
>>
>> but maybe I misunderstood.
>>
>> >
>> >> It might need a tweak to the appropriate plugin, but it's not
>> >> impossible to achieve.
>> >>
>> >
>> > You've not clearly stated what it is that you actually intend to achieve.
>>
>> I thought I stated that clearly in my original post at the start of this
>> thread.
>>
>> >
>> >> The same process would work with the system used by Lucene.
>> >>
>> >> No, it wouldn't. From my reading of that email, there appeared to be far
>> > more manual steps involved, and probably a far larger time window
>> involved
>> > as well. But I'd have to grok it a little more to be sure.
>> >
>> >
>> >>
>> >>
>> > On 26 June 2013 06:48, Hervé BOUTEMY <he...@free.fr> wrote:
>> >> > the jar content isn't updated: so you have jar artifacts inconsistent
>> >> with svn
>> >> >
>> >> > Le mercredi 26 juin 2013 01:08:59 sebb a écrit :
>> >> >> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
>> >> >> > -1
>> >> >> > Except then the poms will point to the wrong place.
>> >> >>
>> >> >> Depends how the poms are updated.
>> >> >>
>> >> >> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory
>> >> > <ga...@gmail.com>wrote:
>> >> >> >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
>> >> >> >> > It would be a lot better to use RC1 RC2 etc initially, and copy
>> the
>> >> >> >> > successful tag to the GA tag.
>> >> >> >>
>> >> >> >> +1 ! :)
>> >> >> >>
>> >> >> >> Gary
>> >> >> >>
>> >> >> >> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>> >> wrote:
>> >> >> >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc
>> after a
>> >> >> >>
>> >> >> >> failed
>> >> >> >>
>> >> >> >> > release vote instead of deleting them.
>> >> >> >> >
>> >> >> >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>> >> >> >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>> >> >> >> >
>> >> >> >> > ralph.goers@dslextreme.com>wrote:
>> >> >> >> > >>> Again I have to disagree. The release manager will send an
>> >> email
>> >> >> >> >
>> >> >> >> > closing
>> >> >> >> >
>> >> >> >> > >>> the prior release. At this point all the prior release
>> >> artifacts
>> >> >> >> > >>> are
>> >> >> >> >
>> >> >> >> > junk
>> >> >> >> >
>> >> >> >> > >>> even if they still exist. At some point the release manager
>> >> will
>> >> >> >> >
>> >> >> >> > delete
>> >> >> >> >
>> >> >> >> > >>> the tag and rerun the release.
>> >> >> >> > >>
>> >> >> >> > >> That's a no-no IMO. Tags that have been voted on should
>> never be
>> >> >> >> >
>> >> >> >> > deleted.
>> >> >> >> >
>> >> >> >> > >> Gary
>> >> >> >> > >>
>> >> >> >> > >>> At this point the tag is still junk to everyone else because
>> >> they
>> >> >> >>
>> >> >> >> have
>> >> >> >>
>> >> >> >> > no
>> >> >> >> >
>> >> >> >> > >>> idea what the RM is doing - so they shouldn't be making
>> >> assumptions
>> >> >> >> >
>> >> >> >> > about
>> >> >> >> >
>> >> >> >> > >>> non-released tags. Once he sends the email though the tag
>> >> will be
>> >> >> >> >
>> >> >> >> > valid.
>> >> >> >> >
>> >> >> >> > >>> Sure having the revision number helps but unless the RM
>> >> completely
>> >> >> >> >
>> >> >> >> > screws
>> >> >> >> >
>> >> >> >> > >>> up the tag should be sufficient.
>> >> >> >> > >>>
>> >> >> >> > >>> Ralph
>> >> >> >> > >>>
>> >> >> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>> >> >> >> > >>>> Not really, no. The developer may have re-spun it again
>> and be
>> >> >> >> > >>>> about
>> >> >> >> >
>> >> >> >> > to
>> >> >> >> >
>> >> >> >> > >>>> email again. You have no idea what you're looking at unless
>> >> you
>> >> >> >> > >>>> know
>> >> >> >> >
>> >> >> >> > the
>> >> >> >> >
>> >> >> >> > >>>> revision. SVN will die off within a decade and this
>> discussion
>> >> >> >> > >>>> will
>> >> >> >> > >>>
>> >> >> >> > >>> become
>> >> >> >> > >>>
>> >> >> >> > >>>> critical. Better to figure out how to support proper
>> >> techniques
>> >> >> >> > >>>> now,
>> >> >> >> > >>>
>> >> >> >> > >>> rather
>> >> >> >> > >>>
>> >> >> >> > >>>> than wait until forced to.
>> >> >> >> > >>>>
>> >> >> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>> >> >> >> >
>> >> >> >> > ralph.goers@dslextreme.com
>> >> >> >> >
>> >> >> >> > >>>> wrote:
>> >> >> >> > >>>>> I disagree that the revision is required. I know that the
>> >> RM is
>> >> >> >> >
>> >> >> >> > going
>> >> >> >> >
>> >> >> >> > >>> to
>> >> >> >> > >>>
>> >> >> >> > >>>>> recreate the tag with each release candidate. Therefore,
>> so
>> >> long
>> >> >> >>
>> >> >> >> as
>> >> >> >>
>> >> >> >> > I
>> >> >> >> >
>> >> >> >> > >>>>> refetch that tag for every release vote I can be confident
>> >> that I
>> >> >> >>
>> >> >> >> am
>> >> >> >>
>> >> >> >> > >>>>> reviewing the release contents.
>> >> >> >> > >>>>>
>> >> >> >> > >>>>> Ralph
>> >> >> >> > >>>>>
>> >> >> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>> >> >> >> > >>>>>> The mission of the ASF is to release software as source,
>> >> and to
>> >> >> >> >
>> >> >> >> > ensure
>> >> >> >> >
>> >> >> >> > >>>>>> that the released source is available under the Apache
>> >> Licence.
>> >> >> >> > >>>>>>
>> >> >> >> > >>>>>> Before a release can be approved it must be voted on by
>> the
>> >> PMC.
>> >> >> >> > >>>>>> The review process needs to establish that the proposed
>> >> source
>> >> >> >> >
>> >> >> >> > release
>> >> >> >> >
>> >> >> >> > >>>>>> meets those aims.
>> >> >> >> > >>>>>>
>> >> >> >> > >>>>>> It's all but impossible for reviewers to examine every
>> >> single
>> >> >> >> > >>>>>> file
>> >> >> >> >
>> >> >> >> > in
>> >> >> >> >
>> >> >> >> > >>>>>> a source archive to determine if it meets the criteria.
>> >> >> >> > >>>>>> And it's not unknown for spurious files to creep into a
>> >> release
>> >> >> >> > >>>>>> (perhaps from a stale workspace - are releases always
>> built
>> >> from
>> >> >> >> > >>>>>> a
>> >> >> >> > >>>>>> fresh checkout of the tag?)
>> >> >> >> > >>>>>>
>> >> >> >> > >>>>>> However, PMCs are also required to check what is added to
>> >> the
>> >> >> >> > >>>>>> SCM
>> >> >> >> > >>>>>> (SVN/Git) to make sure it meets the required license
>> >> criteria.
>> >> >> >> > >>>>>> This is done on an ongoing basis as part of reviewing
>> >> check-ins
>> >> >> >>
>> >> >> >> and
>> >> >> >>
>> >> >> >> > >>>>>> accepting new contributions.
>> >> >> >> > >>>>>> So provided that all the files in the source release are
>> >> also
>> >> >> >> >
>> >> >> >> > present
>> >> >> >> >
>> >> >> >> > >>>>>> in SCM, the PMC can be reasonably sure that the source
>> >> release
>> >> >> >>
>> >> >> >> meets
>> >> >> >>
>> >> >> >> > >>>>>> the ASF criteria.
>> >> >> >> > >>>>>>
>> >> >> >> > >>>>>> Without having the SCM as a database of validated files,
>> >> there
>> >> >> >> > >>>>>> are
>> >> >> >> >
>> >> >> >> > far
>> >> >> >> >
>> >> >> >> > >>>>>> too many files in the average source archive to check
>> >> >> >>
>> >> >> >> individually.
>> >> >> >>
>> >> >> >> > >>>>>> And how would one check their provenance? The obvious way
>> >> is to
>> >> >> >> > >>>>>> compare them with the entries in SCM.
>> >> >> >> > >>>>>>
>> >> >> >> > >>>>>> Therefore, I contend that a release vote does not make
>> sense
>> >> >> >>
>> >> >> >> without
>> >> >> >>
>> >> >> >> > >>>>>> the SCM tag.
>> >> >> >> > >>>>>> In the case of SVN, since tags are not immutable, the
>> vote
>> >> >> >> > >>>>>> e-mail
>> >> >> >> >
>> >> >> >> > also
>> >> >> >> >
>> >> >> >> > >>>>>> needs the revision.
>> >> >> >> > >>>>>>
>> >> >> >> > >>>>>> Whether every reviewer actually checks the source archive
>> >> >> >> > >>>>>> against
>> >> >> >> >
>> >> >> >> > SCM
>> >> >> >> >
>> >> >> >> > >>>>>> is another matter.
>> >> >> >> > >>>>>> But if the required SCM information is not present, it
>> >> would be
>> >> >> >> > >>>>>> difficult to argue that the RM had provided sufficient
>> >> >> >> > >>>>>> information
>> >> >> >> >
>> >> >> >> > for
>> >> >> >> >
>> >> >> >> > >>>>>> a valid review to take place.
>> >> >> >> >
>> >> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> >> >
>> >> >> >> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> >> > >>>>>> For additional commands, e-mail:
>> dev-help@maven.apache.org
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>
>> >> >> >> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> >> > >>>>> For additional commands, e-mail:
>> dev-help@maven.apache.org
>> >> >> >> > >>>
>> >> >> >> > >>>
>> >> -------------------------------------------------------------------
>> >> >> >> > >>> --
>> >> >> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> >> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >> >> > >>
>> >> >> >> > >> --
>> >> >> >> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> >> > >> Java Persistence with Hibernate, Second Edition<
>> >> >> >> >
>> >> >> >> > http://www.manning.com/bauer3/>
>> >> >> >> >
>> >> >> >> > >> JUnit in Action, Second Edition <
>> >> http://www.manning.com/tahchiev/>
>> >> >> >> > >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> >> >> > >> Blog: http://garygregory.wordpress.com
>> >> >> >> > >> Home: http://garygregory.com/
>> >> >> >> > >> Tweet! http://twitter.com/GaryGregory
>> >> >> >> > >
>> >> >> >> > >
>> >> ---------------------------------------------------------------------
>> >> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >> >>
>> >> >> >> --
>> >> >> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> >> Java Persistence with Hibernate, Second Edition<
>> >> >> >> http://www.manning.com/bauer3/>
>> >> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
>> >
>> >> >> >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> >> >> Blog: http://garygregory.wordpress.com
>> >> >> >> Home: http://garygregory.com/
>> >> >> >> Tweet! http://twitter.com/GaryGregory
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Hello there,
when. respinning a release it would of help IMO instead of deleting the tag
to rename it to e.g. maven-javadoc-plugin-2.9-rc1 using "svn mv".
By means of this you are able to easily diff between e.g. released 2.8 and
the final 2.9 as well as between 2.9-rc1 and the final 2.9.
Regards Mirko
--
Sent from my mobile
On Jun 26, 2013 12:14 PM, "sebb" <se...@gmail.com> wrote:
> On 26 June 2013 10:56, Chris Graham <ch...@gmail.com> wrote:
> > On Wed, Jun 26, 2013 at 7:06 PM, sebb <se...@gmail.com> wrote:
> >
> >> I meant: if the pom is created with the correct final URLs in the
> >> first place, it won't have to be changed.
> >>
> >>
> > They are. If you'd used the release plugin, then you would have seen
> this.
> >
>
> I was responding to this:
>
> >>>
> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
> > -1
> > Except then the poms will point to the wrong place.
> <<<
>
> but maybe I misunderstood.
>
> >
> >> It might need a tweak to the appropriate plugin, but it's not
> >> impossible to achieve.
> >>
> >
> > You've not clearly stated what it is that you actually intend to achieve.
>
> I thought I stated that clearly in my original post at the start of this
> thread.
>
> >
> >> The same process would work with the system used by Lucene.
> >>
> >> No, it wouldn't. From my reading of that email, there appeared to be far
> > more manual steps involved, and probably a far larger time window
> involved
> > as well. But I'd have to grok it a little more to be sure.
> >
> >
> >>
> >>
> > On 26 June 2013 06:48, Hervé BOUTEMY <he...@free.fr> wrote:
> >> > the jar content isn't updated: so you have jar artifacts inconsistent
> >> with svn
> >> >
> >> > Le mercredi 26 juin 2013 01:08:59 sebb a écrit :
> >> >> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
> >> >> > -1
> >> >> > Except then the poms will point to the wrong place.
> >> >>
> >> >> Depends how the poms are updated.
> >> >>
> >> >> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory
> >> > <ga...@gmail.com>wrote:
> >> >> >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
> >> >> >> > It would be a lot better to use RC1 RC2 etc initially, and copy
> the
> >> >> >> > successful tag to the GA tag.
> >> >> >>
> >> >> >> +1 ! :)
> >> >> >>
> >> >> >> Gary
> >> >> >>
> >> >> >> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
> >> wrote:
> >> >> >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc
> after a
> >> >> >>
> >> >> >> failed
> >> >> >>
> >> >> >> > release vote instead of deleting them.
> >> >> >> >
> >> >> >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >> >> >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> >> >> >> >
> >> >> >> > ralph.goers@dslextreme.com>wrote:
> >> >> >> > >>> Again I have to disagree. The release manager will send an
> >> email
> >> >> >> >
> >> >> >> > closing
> >> >> >> >
> >> >> >> > >>> the prior release. At this point all the prior release
> >> artifacts
> >> >> >> > >>> are
> >> >> >> >
> >> >> >> > junk
> >> >> >> >
> >> >> >> > >>> even if they still exist. At some point the release manager
> >> will
> >> >> >> >
> >> >> >> > delete
> >> >> >> >
> >> >> >> > >>> the tag and rerun the release.
> >> >> >> > >>
> >> >> >> > >> That's a no-no IMO. Tags that have been voted on should
> never be
> >> >> >> >
> >> >> >> > deleted.
> >> >> >> >
> >> >> >> > >> Gary
> >> >> >> > >>
> >> >> >> > >>> At this point the tag is still junk to everyone else because
> >> they
> >> >> >>
> >> >> >> have
> >> >> >>
> >> >> >> > no
> >> >> >> >
> >> >> >> > >>> idea what the RM is doing - so they shouldn't be making
> >> assumptions
> >> >> >> >
> >> >> >> > about
> >> >> >> >
> >> >> >> > >>> non-released tags. Once he sends the email though the tag
> >> will be
> >> >> >> >
> >> >> >> > valid.
> >> >> >> >
> >> >> >> > >>> Sure having the revision number helps but unless the RM
> >> completely
> >> >> >> >
> >> >> >> > screws
> >> >> >> >
> >> >> >> > >>> up the tag should be sufficient.
> >> >> >> > >>>
> >> >> >> > >>> Ralph
> >> >> >> > >>>
> >> >> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >> >> >> > >>>> Not really, no. The developer may have re-spun it again
> and be
> >> >> >> > >>>> about
> >> >> >> >
> >> >> >> > to
> >> >> >> >
> >> >> >> > >>>> email again. You have no idea what you're looking at unless
> >> you
> >> >> >> > >>>> know
> >> >> >> >
> >> >> >> > the
> >> >> >> >
> >> >> >> > >>>> revision. SVN will die off within a decade and this
> discussion
> >> >> >> > >>>> will
> >> >> >> > >>>
> >> >> >> > >>> become
> >> >> >> > >>>
> >> >> >> > >>>> critical. Better to figure out how to support proper
> >> techniques
> >> >> >> > >>>> now,
> >> >> >> > >>>
> >> >> >> > >>> rather
> >> >> >> > >>>
> >> >> >> > >>>> than wait until forced to.
> >> >> >> > >>>>
> >> >> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> >> >> >> >
> >> >> >> > ralph.goers@dslextreme.com
> >> >> >> >
> >> >> >> > >>>> wrote:
> >> >> >> > >>>>> I disagree that the revision is required. I know that the
> >> RM is
> >> >> >> >
> >> >> >> > going
> >> >> >> >
> >> >> >> > >>> to
> >> >> >> > >>>
> >> >> >> > >>>>> recreate the tag with each release candidate. Therefore,
> so
> >> long
> >> >> >>
> >> >> >> as
> >> >> >>
> >> >> >> > I
> >> >> >> >
> >> >> >> > >>>>> refetch that tag for every release vote I can be confident
> >> that I
> >> >> >>
> >> >> >> am
> >> >> >>
> >> >> >> > >>>>> reviewing the release contents.
> >> >> >> > >>>>>
> >> >> >> > >>>>> Ralph
> >> >> >> > >>>>>
> >> >> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >> >> >> > >>>>>> The mission of the ASF is to release software as source,
> >> and to
> >> >> >> >
> >> >> >> > ensure
> >> >> >> >
> >> >> >> > >>>>>> that the released source is available under the Apache
> >> Licence.
> >> >> >> > >>>>>>
> >> >> >> > >>>>>> Before a release can be approved it must be voted on by
> the
> >> PMC.
> >> >> >> > >>>>>> The review process needs to establish that the proposed
> >> source
> >> >> >> >
> >> >> >> > release
> >> >> >> >
> >> >> >> > >>>>>> meets those aims.
> >> >> >> > >>>>>>
> >> >> >> > >>>>>> It's all but impossible for reviewers to examine every
> >> single
> >> >> >> > >>>>>> file
> >> >> >> >
> >> >> >> > in
> >> >> >> >
> >> >> >> > >>>>>> a source archive to determine if it meets the criteria.
> >> >> >> > >>>>>> And it's not unknown for spurious files to creep into a
> >> release
> >> >> >> > >>>>>> (perhaps from a stale workspace - are releases always
> built
> >> from
> >> >> >> > >>>>>> a
> >> >> >> > >>>>>> fresh checkout of the tag?)
> >> >> >> > >>>>>>
> >> >> >> > >>>>>> However, PMCs are also required to check what is added to
> >> the
> >> >> >> > >>>>>> SCM
> >> >> >> > >>>>>> (SVN/Git) to make sure it meets the required license
> >> criteria.
> >> >> >> > >>>>>> This is done on an ongoing basis as part of reviewing
> >> check-ins
> >> >> >>
> >> >> >> and
> >> >> >>
> >> >> >> > >>>>>> accepting new contributions.
> >> >> >> > >>>>>> So provided that all the files in the source release are
> >> also
> >> >> >> >
> >> >> >> > present
> >> >> >> >
> >> >> >> > >>>>>> in SCM, the PMC can be reasonably sure that the source
> >> release
> >> >> >>
> >> >> >> meets
> >> >> >>
> >> >> >> > >>>>>> the ASF criteria.
> >> >> >> > >>>>>>
> >> >> >> > >>>>>> Without having the SCM as a database of validated files,
> >> there
> >> >> >> > >>>>>> are
> >> >> >> >
> >> >> >> > far
> >> >> >> >
> >> >> >> > >>>>>> too many files in the average source archive to check
> >> >> >>
> >> >> >> individually.
> >> >> >>
> >> >> >> > >>>>>> And how would one check their provenance? The obvious way
> >> is to
> >> >> >> > >>>>>> compare them with the entries in SCM.
> >> >> >> > >>>>>>
> >> >> >> > >>>>>> Therefore, I contend that a release vote does not make
> sense
> >> >> >>
> >> >> >> without
> >> >> >>
> >> >> >> > >>>>>> the SCM tag.
> >> >> >> > >>>>>> In the case of SVN, since tags are not immutable, the
> vote
> >> >> >> > >>>>>> e-mail
> >> >> >> >
> >> >> >> > also
> >> >> >> >
> >> >> >> > >>>>>> needs the revision.
> >> >> >> > >>>>>>
> >> >> >> > >>>>>> Whether every reviewer actually checks the source archive
> >> >> >> > >>>>>> against
> >> >> >> >
> >> >> >> > SCM
> >> >> >> >
> >> >> >> > >>>>>> is another matter.
> >> >> >> > >>>>>> But if the required SCM information is not present, it
> >> would be
> >> >> >> > >>>>>> difficult to argue that the RM had provided sufficient
> >> >> >> > >>>>>> information
> >> >> >> >
> >> >> >> > for
> >> >> >> >
> >> >> >> > >>>>>> a valid review to take place.
> >> >> >> >
> >> >> >> >
> >> ---------------------------------------------------------------------
> >> >> >> >
> >> >> >> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> > >>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >>
> >> >> >> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> > >>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >> >> >> > >>>
> >> >> >> > >>>
> >> -------------------------------------------------------------------
> >> >> >> > >>> --
> >> >> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >> > >>
> >> >> >> > >> --
> >> >> >> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >> >> > >> Java Persistence with Hibernate, Second Edition<
> >> >> >> >
> >> >> >> > http://www.manning.com/bauer3/>
> >> >> >> >
> >> >> >> > >> JUnit in Action, Second Edition <
> >> http://www.manning.com/tahchiev/>
> >> >> >> > >> Spring Batch in Action <http://www.manning.com/templier/>
> >> >> >> > >> Blog: http://garygregory.wordpress.com
> >> >> >> > >> Home: http://garygregory.com/
> >> >> >> > >> Tweet! http://twitter.com/GaryGregory
> >> >> >> > >
> >> >> >> > >
> >> ---------------------------------------------------------------------
> >> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >> >
> >> >> >> >
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>
> >> >> >> --
> >> >> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >> >> Java Persistence with Hibernate, Second Edition<
> >> >> >> http://www.manning.com/bauer3/>
> >> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
> >
> >> >> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> >> >> Blog: http://garygregory.wordpress.com
> >> >> >> Home: http://garygregory.com/
> >> >> >> Tweet! http://twitter.com/GaryGregory
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 10:56, Chris Graham <ch...@gmail.com> wrote:
> On Wed, Jun 26, 2013 at 7:06 PM, sebb <se...@gmail.com> wrote:
>
>> I meant: if the pom is created with the correct final URLs in the
>> first place, it won't have to be changed.
>>
>>
> They are. If you'd used the release plugin, then you would have seen this.
>
I was responding to this:
>>>
On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
> -1
> Except then the poms will point to the wrong place.
<<<
but maybe I misunderstood.
>
>> It might need a tweak to the appropriate plugin, but it's not
>> impossible to achieve.
>>
>
> You've not clearly stated what it is that you actually intend to achieve.
I thought I stated that clearly in my original post at the start of this thread.
>
>> The same process would work with the system used by Lucene.
>>
>> No, it wouldn't. From my reading of that email, there appeared to be far
> more manual steps involved, and probably a far larger time window involved
> as well. But I'd have to grok it a little more to be sure.
>
>
>>
>>
> On 26 June 2013 06:48, Hervé BOUTEMY <he...@free.fr> wrote:
>> > the jar content isn't updated: so you have jar artifacts inconsistent
>> with svn
>> >
>> > Le mercredi 26 juin 2013 01:08:59 sebb a écrit :
>> >> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
>> >> > -1
>> >> > Except then the poms will point to the wrong place.
>> >>
>> >> Depends how the poms are updated.
>> >>
>> >> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory
>> > <ga...@gmail.com>wrote:
>> >> >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
>> >> >> > It would be a lot better to use RC1 RC2 etc initially, and copy the
>> >> >> > successful tag to the GA tag.
>> >> >>
>> >> >> +1 ! :)
>> >> >>
>> >> >> Gary
>> >> >>
>> >> >> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>> >> >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>> >> >>
>> >> >> failed
>> >> >>
>> >> >> > release vote instead of deleting them.
>> >> >> >
>> >> >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>> >> >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>> >> >> >
>> >> >> > ralph.goers@dslextreme.com>wrote:
>> >> >> > >>> Again I have to disagree. The release manager will send an
>> email
>> >> >> >
>> >> >> > closing
>> >> >> >
>> >> >> > >>> the prior release. At this point all the prior release
>> artifacts
>> >> >> > >>> are
>> >> >> >
>> >> >> > junk
>> >> >> >
>> >> >> > >>> even if they still exist. At some point the release manager
>> will
>> >> >> >
>> >> >> > delete
>> >> >> >
>> >> >> > >>> the tag and rerun the release.
>> >> >> > >>
>> >> >> > >> That's a no-no IMO. Tags that have been voted on should never be
>> >> >> >
>> >> >> > deleted.
>> >> >> >
>> >> >> > >> Gary
>> >> >> > >>
>> >> >> > >>> At this point the tag is still junk to everyone else because
>> they
>> >> >>
>> >> >> have
>> >> >>
>> >> >> > no
>> >> >> >
>> >> >> > >>> idea what the RM is doing - so they shouldn't be making
>> assumptions
>> >> >> >
>> >> >> > about
>> >> >> >
>> >> >> > >>> non-released tags. Once he sends the email though the tag
>> will be
>> >> >> >
>> >> >> > valid.
>> >> >> >
>> >> >> > >>> Sure having the revision number helps but unless the RM
>> completely
>> >> >> >
>> >> >> > screws
>> >> >> >
>> >> >> > >>> up the tag should be sufficient.
>> >> >> > >>>
>> >> >> > >>> Ralph
>> >> >> > >>>
>> >> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>> >> >> > >>>> Not really, no. The developer may have re-spun it again and be
>> >> >> > >>>> about
>> >> >> >
>> >> >> > to
>> >> >> >
>> >> >> > >>>> email again. You have no idea what you're looking at unless
>> you
>> >> >> > >>>> know
>> >> >> >
>> >> >> > the
>> >> >> >
>> >> >> > >>>> revision. SVN will die off within a decade and this discussion
>> >> >> > >>>> will
>> >> >> > >>>
>> >> >> > >>> become
>> >> >> > >>>
>> >> >> > >>>> critical. Better to figure out how to support proper
>> techniques
>> >> >> > >>>> now,
>> >> >> > >>>
>> >> >> > >>> rather
>> >> >> > >>>
>> >> >> > >>>> than wait until forced to.
>> >> >> > >>>>
>> >> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>> >> >> >
>> >> >> > ralph.goers@dslextreme.com
>> >> >> >
>> >> >> > >>>> wrote:
>> >> >> > >>>>> I disagree that the revision is required. I know that the
>> RM is
>> >> >> >
>> >> >> > going
>> >> >> >
>> >> >> > >>> to
>> >> >> > >>>
>> >> >> > >>>>> recreate the tag with each release candidate. Therefore, so
>> long
>> >> >>
>> >> >> as
>> >> >>
>> >> >> > I
>> >> >> >
>> >> >> > >>>>> refetch that tag for every release vote I can be confident
>> that I
>> >> >>
>> >> >> am
>> >> >>
>> >> >> > >>>>> reviewing the release contents.
>> >> >> > >>>>>
>> >> >> > >>>>> Ralph
>> >> >> > >>>>>
>> >> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>> >> >> > >>>>>> The mission of the ASF is to release software as source,
>> and to
>> >> >> >
>> >> >> > ensure
>> >> >> >
>> >> >> > >>>>>> that the released source is available under the Apache
>> Licence.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Before a release can be approved it must be voted on by the
>> PMC.
>> >> >> > >>>>>> The review process needs to establish that the proposed
>> source
>> >> >> >
>> >> >> > release
>> >> >> >
>> >> >> > >>>>>> meets those aims.
>> >> >> > >>>>>>
>> >> >> > >>>>>> It's all but impossible for reviewers to examine every
>> single
>> >> >> > >>>>>> file
>> >> >> >
>> >> >> > in
>> >> >> >
>> >> >> > >>>>>> a source archive to determine if it meets the criteria.
>> >> >> > >>>>>> And it's not unknown for spurious files to creep into a
>> release
>> >> >> > >>>>>> (perhaps from a stale workspace - are releases always built
>> from
>> >> >> > >>>>>> a
>> >> >> > >>>>>> fresh checkout of the tag?)
>> >> >> > >>>>>>
>> >> >> > >>>>>> However, PMCs are also required to check what is added to
>> the
>> >> >> > >>>>>> SCM
>> >> >> > >>>>>> (SVN/Git) to make sure it meets the required license
>> criteria.
>> >> >> > >>>>>> This is done on an ongoing basis as part of reviewing
>> check-ins
>> >> >>
>> >> >> and
>> >> >>
>> >> >> > >>>>>> accepting new contributions.
>> >> >> > >>>>>> So provided that all the files in the source release are
>> also
>> >> >> >
>> >> >> > present
>> >> >> >
>> >> >> > >>>>>> in SCM, the PMC can be reasonably sure that the source
>> release
>> >> >>
>> >> >> meets
>> >> >>
>> >> >> > >>>>>> the ASF criteria.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Without having the SCM as a database of validated files,
>> there
>> >> >> > >>>>>> are
>> >> >> >
>> >> >> > far
>> >> >> >
>> >> >> > >>>>>> too many files in the average source archive to check
>> >> >>
>> >> >> individually.
>> >> >>
>> >> >> > >>>>>> And how would one check their provenance? The obvious way
>> is to
>> >> >> > >>>>>> compare them with the entries in SCM.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Therefore, I contend that a release vote does not make sense
>> >> >>
>> >> >> without
>> >> >>
>> >> >> > >>>>>> the SCM tag.
>> >> >> > >>>>>> In the case of SVN, since tags are not immutable, the vote
>> >> >> > >>>>>> e-mail
>> >> >> >
>> >> >> > also
>> >> >> >
>> >> >> > >>>>>> needs the revision.
>> >> >> > >>>>>>
>> >> >> > >>>>>> Whether every reviewer actually checks the source archive
>> >> >> > >>>>>> against
>> >> >> >
>> >> >> > SCM
>> >> >> >
>> >> >> > >>>>>> is another matter.
>> >> >> > >>>>>> But if the required SCM information is not present, it
>> would be
>> >> >> > >>>>>> difficult to argue that the RM had provided sufficient
>> >> >> > >>>>>> information
>> >> >> >
>> >> >> > for
>> >> >> >
>> >> >> > >>>>>> a valid review to take place.
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> >
>> >> >> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >>
>> >> >> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >> > >>>
>> >> >> > >>>
>> -------------------------------------------------------------------
>> >> >> > >>> --
>> >> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >> > >>
>> >> >> > >> --
>> >> >> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> > >> Java Persistence with Hibernate, Second Edition<
>> >> >> >
>> >> >> > http://www.manning.com/bauer3/>
>> >> >> >
>> >> >> > >> JUnit in Action, Second Edition <
>> http://www.manning.com/tahchiev/>
>> >> >> > >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> >> > >> Blog: http://garygregory.wordpress.com
>> >> >> > >> Home: http://garygregory.com/
>> >> >> > >> Tweet! http://twitter.com/GaryGregory
>> >> >> > >
>> >> >> > >
>> ---------------------------------------------------------------------
>> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >> --
>> >> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> Java Persistence with Hibernate, Second Edition<
>> >> >> http://www.manning.com/bauer3/>
>> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >> >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> >> Blog: http://garygregory.wordpress.com
>> >> >> Home: http://garygregory.com/
>> >> >> Tweet! http://twitter.com/GaryGregory
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
On Wed, Jun 26, 2013 at 7:06 PM, sebb <se...@gmail.com> wrote:
> I meant: if the pom is created with the correct final URLs in the
> first place, it won't have to be changed.
>
>
They are. If you'd used the release plugin, then you would have seen this.
> It might need a tweak to the appropriate plugin, but it's not
> impossible to achieve.
>
You've not clearly stated what it is that you actually intend to achieve.
> The same process would work with the system used by Lucene.
>
> No, it wouldn't. From my reading of that email, there appeared to be far
more manual steps involved, and probably a far larger time window involved
as well. But I'd have to grok it a little more to be sure.
>
>
On 26 June 2013 06:48, Hervé BOUTEMY <he...@free.fr> wrote:
> > the jar content isn't updated: so you have jar artifacts inconsistent
> with svn
> >
> > Le mercredi 26 juin 2013 01:08:59 sebb a écrit :
> >> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
> >> > -1
> >> > Except then the poms will point to the wrong place.
> >>
> >> Depends how the poms are updated.
> >>
> >> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory
> > <ga...@gmail.com>wrote:
> >> >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
> >> >> > It would be a lot better to use RC1 RC2 etc initially, and copy the
> >> >> > successful tag to the GA tag.
> >> >>
> >> >> +1 ! :)
> >> >>
> >> >> Gary
> >> >>
> >> >> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >> >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a
> >> >>
> >> >> failed
> >> >>
> >> >> > release vote instead of deleting them.
> >> >> >
> >> >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >> >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> >> >> >
> >> >> > ralph.goers@dslextreme.com>wrote:
> >> >> > >>> Again I have to disagree. The release manager will send an
> email
> >> >> >
> >> >> > closing
> >> >> >
> >> >> > >>> the prior release. At this point all the prior release
> artifacts
> >> >> > >>> are
> >> >> >
> >> >> > junk
> >> >> >
> >> >> > >>> even if they still exist. At some point the release manager
> will
> >> >> >
> >> >> > delete
> >> >> >
> >> >> > >>> the tag and rerun the release.
> >> >> > >>
> >> >> > >> That's a no-no IMO. Tags that have been voted on should never be
> >> >> >
> >> >> > deleted.
> >> >> >
> >> >> > >> Gary
> >> >> > >>
> >> >> > >>> At this point the tag is still junk to everyone else because
> they
> >> >>
> >> >> have
> >> >>
> >> >> > no
> >> >> >
> >> >> > >>> idea what the RM is doing - so they shouldn't be making
> assumptions
> >> >> >
> >> >> > about
> >> >> >
> >> >> > >>> non-released tags. Once he sends the email though the tag
> will be
> >> >> >
> >> >> > valid.
> >> >> >
> >> >> > >>> Sure having the revision number helps but unless the RM
> completely
> >> >> >
> >> >> > screws
> >> >> >
> >> >> > >>> up the tag should be sufficient.
> >> >> > >>>
> >> >> > >>> Ralph
> >> >> > >>>
> >> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >> >> > >>>> Not really, no. The developer may have re-spun it again and be
> >> >> > >>>> about
> >> >> >
> >> >> > to
> >> >> >
> >> >> > >>>> email again. You have no idea what you're looking at unless
> you
> >> >> > >>>> know
> >> >> >
> >> >> > the
> >> >> >
> >> >> > >>>> revision. SVN will die off within a decade and this discussion
> >> >> > >>>> will
> >> >> > >>>
> >> >> > >>> become
> >> >> > >>>
> >> >> > >>>> critical. Better to figure out how to support proper
> techniques
> >> >> > >>>> now,
> >> >> > >>>
> >> >> > >>> rather
> >> >> > >>>
> >> >> > >>>> than wait until forced to.
> >> >> > >>>>
> >> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> >> >> >
> >> >> > ralph.goers@dslextreme.com
> >> >> >
> >> >> > >>>> wrote:
> >> >> > >>>>> I disagree that the revision is required. I know that the
> RM is
> >> >> >
> >> >> > going
> >> >> >
> >> >> > >>> to
> >> >> > >>>
> >> >> > >>>>> recreate the tag with each release candidate. Therefore, so
> long
> >> >>
> >> >> as
> >> >>
> >> >> > I
> >> >> >
> >> >> > >>>>> refetch that tag for every release vote I can be confident
> that I
> >> >>
> >> >> am
> >> >>
> >> >> > >>>>> reviewing the release contents.
> >> >> > >>>>>
> >> >> > >>>>> Ralph
> >> >> > >>>>>
> >> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >> >> > >>>>>> The mission of the ASF is to release software as source,
> and to
> >> >> >
> >> >> > ensure
> >> >> >
> >> >> > >>>>>> that the released source is available under the Apache
> Licence.
> >> >> > >>>>>>
> >> >> > >>>>>> Before a release can be approved it must be voted on by the
> PMC.
> >> >> > >>>>>> The review process needs to establish that the proposed
> source
> >> >> >
> >> >> > release
> >> >> >
> >> >> > >>>>>> meets those aims.
> >> >> > >>>>>>
> >> >> > >>>>>> It's all but impossible for reviewers to examine every
> single
> >> >> > >>>>>> file
> >> >> >
> >> >> > in
> >> >> >
> >> >> > >>>>>> a source archive to determine if it meets the criteria.
> >> >> > >>>>>> And it's not unknown for spurious files to creep into a
> release
> >> >> > >>>>>> (perhaps from a stale workspace - are releases always built
> from
> >> >> > >>>>>> a
> >> >> > >>>>>> fresh checkout of the tag?)
> >> >> > >>>>>>
> >> >> > >>>>>> However, PMCs are also required to check what is added to
> the
> >> >> > >>>>>> SCM
> >> >> > >>>>>> (SVN/Git) to make sure it meets the required license
> criteria.
> >> >> > >>>>>> This is done on an ongoing basis as part of reviewing
> check-ins
> >> >>
> >> >> and
> >> >>
> >> >> > >>>>>> accepting new contributions.
> >> >> > >>>>>> So provided that all the files in the source release are
> also
> >> >> >
> >> >> > present
> >> >> >
> >> >> > >>>>>> in SCM, the PMC can be reasonably sure that the source
> release
> >> >>
> >> >> meets
> >> >>
> >> >> > >>>>>> the ASF criteria.
> >> >> > >>>>>>
> >> >> > >>>>>> Without having the SCM as a database of validated files,
> there
> >> >> > >>>>>> are
> >> >> >
> >> >> > far
> >> >> >
> >> >> > >>>>>> too many files in the average source archive to check
> >> >>
> >> >> individually.
> >> >>
> >> >> > >>>>>> And how would one check their provenance? The obvious way
> is to
> >> >> > >>>>>> compare them with the entries in SCM.
> >> >> > >>>>>>
> >> >> > >>>>>> Therefore, I contend that a release vote does not make sense
> >> >>
> >> >> without
> >> >>
> >> >> > >>>>>> the SCM tag.
> >> >> > >>>>>> In the case of SVN, since tags are not immutable, the vote
> >> >> > >>>>>> e-mail
> >> >> >
> >> >> > also
> >> >> >
> >> >> > >>>>>> needs the revision.
> >> >> > >>>>>>
> >> >> > >>>>>> Whether every reviewer actually checks the source archive
> >> >> > >>>>>> against
> >> >> >
> >> >> > SCM
> >> >> >
> >> >> > >>>>>> is another matter.
> >> >> > >>>>>> But if the required SCM information is not present, it
> would be
> >> >> > >>>>>> difficult to argue that the RM had provided sufficient
> >> >> > >>>>>> information
> >> >> >
> >> >> > for
> >> >> >
> >> >> > >>>>>> a valid review to take place.
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> >
> >> >> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>
> >> >> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> > >>>
> >> >> > >>>
> -------------------------------------------------------------------
> >> >> > >>> --
> >> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> > >>
> >> >> > >> --
> >> >> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >> > >> Java Persistence with Hibernate, Second Edition<
> >> >> >
> >> >> > http://www.manning.com/bauer3/>
> >> >> >
> >> >> > >> JUnit in Action, Second Edition <
> http://www.manning.com/tahchiev/>
> >> >> > >> Spring Batch in Action <http://www.manning.com/templier/>
> >> >> > >> Blog: http://garygregory.wordpress.com
> >> >> > >> Home: http://garygregory.com/
> >> >> > >> Tweet! http://twitter.com/GaryGregory
> >> >> > >
> >> >> > >
> ---------------------------------------------------------------------
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> --
> >> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >> Java Persistence with Hibernate, Second Edition<
> >> >> http://www.manning.com/bauer3/>
> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> >> Blog: http://garygregory.wordpress.com
> >> >> Home: http://garygregory.com/
> >> >> Tweet! http://twitter.com/GaryGregory
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by sebb <se...@gmail.com>.
I meant: if the pom is created with the correct final URLs in the
first place, it won't have to be changed.
It might need a tweak to the appropriate plugin, but it's not
impossible to achieve.
The same process would work with the system used by Lucene.
On 26 June 2013 06:48, Hervé BOUTEMY <he...@free.fr> wrote:
> the jar content isn't updated: so you have jar artifacts inconsistent with svn
>
> Le mercredi 26 juin 2013 01:08:59 sebb a écrit :
>> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
>> > -1
>> > Except then the poms will point to the wrong place.
>>
>> Depends how the poms are updated.
>>
>> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory
> <ga...@gmail.com>wrote:
>> >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
>> >> > It would be a lot better to use RC1 RC2 etc initially, and copy the
>> >> > successful tag to the GA tag.
>> >>
>> >> +1 ! :)
>> >>
>> >> Gary
>> >>
>> >> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>> >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>> >>
>> >> failed
>> >>
>> >> > release vote instead of deleting them.
>> >> >
>> >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>> >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>> >> >
>> >> > ralph.goers@dslextreme.com>wrote:
>> >> > >>> Again I have to disagree. The release manager will send an email
>> >> >
>> >> > closing
>> >> >
>> >> > >>> the prior release. At this point all the prior release artifacts
>> >> > >>> are
>> >> >
>> >> > junk
>> >> >
>> >> > >>> even if they still exist. At some point the release manager will
>> >> >
>> >> > delete
>> >> >
>> >> > >>> the tag and rerun the release.
>> >> > >>
>> >> > >> That's a no-no IMO. Tags that have been voted on should never be
>> >> >
>> >> > deleted.
>> >> >
>> >> > >> Gary
>> >> > >>
>> >> > >>> At this point the tag is still junk to everyone else because they
>> >>
>> >> have
>> >>
>> >> > no
>> >> >
>> >> > >>> idea what the RM is doing - so they shouldn't be making assumptions
>> >> >
>> >> > about
>> >> >
>> >> > >>> non-released tags. Once he sends the email though the tag will be
>> >> >
>> >> > valid.
>> >> >
>> >> > >>> Sure having the revision number helps but unless the RM completely
>> >> >
>> >> > screws
>> >> >
>> >> > >>> up the tag should be sufficient.
>> >> > >>>
>> >> > >>> Ralph
>> >> > >>>
>> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>> >> > >>>> Not really, no. The developer may have re-spun it again and be
>> >> > >>>> about
>> >> >
>> >> > to
>> >> >
>> >> > >>>> email again. You have no idea what you're looking at unless you
>> >> > >>>> know
>> >> >
>> >> > the
>> >> >
>> >> > >>>> revision. SVN will die off within a decade and this discussion
>> >> > >>>> will
>> >> > >>>
>> >> > >>> become
>> >> > >>>
>> >> > >>>> critical. Better to figure out how to support proper techniques
>> >> > >>>> now,
>> >> > >>>
>> >> > >>> rather
>> >> > >>>
>> >> > >>>> than wait until forced to.
>> >> > >>>>
>> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>> >> >
>> >> > ralph.goers@dslextreme.com
>> >> >
>> >> > >>>> wrote:
>> >> > >>>>> I disagree that the revision is required. I know that the RM is
>> >> >
>> >> > going
>> >> >
>> >> > >>> to
>> >> > >>>
>> >> > >>>>> recreate the tag with each release candidate. Therefore, so long
>> >>
>> >> as
>> >>
>> >> > I
>> >> >
>> >> > >>>>> refetch that tag for every release vote I can be confident that I
>> >>
>> >> am
>> >>
>> >> > >>>>> reviewing the release contents.
>> >> > >>>>>
>> >> > >>>>> Ralph
>> >> > >>>>>
>> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>> >> > >>>>>> The mission of the ASF is to release software as source, and to
>> >> >
>> >> > ensure
>> >> >
>> >> > >>>>>> that the released source is available under the Apache Licence.
>> >> > >>>>>>
>> >> > >>>>>> Before a release can be approved it must be voted on by the PMC.
>> >> > >>>>>> The review process needs to establish that the proposed source
>> >> >
>> >> > release
>> >> >
>> >> > >>>>>> meets those aims.
>> >> > >>>>>>
>> >> > >>>>>> It's all but impossible for reviewers to examine every single
>> >> > >>>>>> file
>> >> >
>> >> > in
>> >> >
>> >> > >>>>>> a source archive to determine if it meets the criteria.
>> >> > >>>>>> And it's not unknown for spurious files to creep into a release
>> >> > >>>>>> (perhaps from a stale workspace - are releases always built from
>> >> > >>>>>> a
>> >> > >>>>>> fresh checkout of the tag?)
>> >> > >>>>>>
>> >> > >>>>>> However, PMCs are also required to check what is added to the
>> >> > >>>>>> SCM
>> >> > >>>>>> (SVN/Git) to make sure it meets the required license criteria.
>> >> > >>>>>> This is done on an ongoing basis as part of reviewing check-ins
>> >>
>> >> and
>> >>
>> >> > >>>>>> accepting new contributions.
>> >> > >>>>>> So provided that all the files in the source release are also
>> >> >
>> >> > present
>> >> >
>> >> > >>>>>> in SCM, the PMC can be reasonably sure that the source release
>> >>
>> >> meets
>> >>
>> >> > >>>>>> the ASF criteria.
>> >> > >>>>>>
>> >> > >>>>>> Without having the SCM as a database of validated files, there
>> >> > >>>>>> are
>> >> >
>> >> > far
>> >> >
>> >> > >>>>>> too many files in the average source archive to check
>> >>
>> >> individually.
>> >>
>> >> > >>>>>> And how would one check their provenance? The obvious way is to
>> >> > >>>>>> compare them with the entries in SCM.
>> >> > >>>>>>
>> >> > >>>>>> Therefore, I contend that a release vote does not make sense
>> >>
>> >> without
>> >>
>> >> > >>>>>> the SCM tag.
>> >> > >>>>>> In the case of SVN, since tags are not immutable, the vote
>> >> > >>>>>> e-mail
>> >> >
>> >> > also
>> >> >
>> >> > >>>>>> needs the revision.
>> >> > >>>>>>
>> >> > >>>>>> Whether every reviewer actually checks the source archive
>> >> > >>>>>> against
>> >> >
>> >> > SCM
>> >> >
>> >> > >>>>>> is another matter.
>> >> > >>>>>> But if the required SCM information is not present, it would be
>> >> > >>>>>> difficult to argue that the RM had provided sufficient
>> >> > >>>>>> information
>> >> >
>> >> > for
>> >> >
>> >> > >>>>>> a valid review to take place.
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> >
>> >> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> > >>>
>> >> > >>> -------------------------------------------------------------------
>> >> > >>> --
>> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> > >>
>> >> > >> --
>> >> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> > >> Java Persistence with Hibernate, Second Edition<
>> >> >
>> >> > http://www.manning.com/bauer3/>
>> >> >
>> >> > >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >> > >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> > >> Blog: http://garygregory.wordpress.com
>> >> > >> Home: http://garygregory.com/
>> >> > >> Tweet! http://twitter.com/GaryGregory
>> >> > >
>> >> > > ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> --
>> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> Java Persistence with Hibernate, Second Edition<
>> >> http://www.manning.com/bauer3/>
>> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> Blog: http://garygregory.wordpress.com
>> >> Home: http://garygregory.com/
>> >> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Hervé BOUTEMY <he...@free.fr>.
the jar content isn't updated: so you have jar artifacts inconsistent with svn
Le mercredi 26 juin 2013 01:08:59 sebb a écrit :
> On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
> > -1
> > Except then the poms will point to the wrong place.
>
> Depends how the poms are updated.
>
> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory
<ga...@gmail.com>wrote:
> >> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
> >> > It would be a lot better to use RC1 RC2 etc initially, and copy the
> >> > successful tag to the GA tag.
> >>
> >> +1 ! :)
> >>
> >> Gary
> >>
> >> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
> >> > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a
> >>
> >> failed
> >>
> >> > release vote instead of deleting them.
> >> >
> >> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> >> >
> >> > ralph.goers@dslextreme.com>wrote:
> >> > >>> Again I have to disagree. The release manager will send an email
> >> >
> >> > closing
> >> >
> >> > >>> the prior release. At this point all the prior release artifacts
> >> > >>> are
> >> >
> >> > junk
> >> >
> >> > >>> even if they still exist. At some point the release manager will
> >> >
> >> > delete
> >> >
> >> > >>> the tag and rerun the release.
> >> > >>
> >> > >> That's a no-no IMO. Tags that have been voted on should never be
> >> >
> >> > deleted.
> >> >
> >> > >> Gary
> >> > >>
> >> > >>> At this point the tag is still junk to everyone else because they
> >>
> >> have
> >>
> >> > no
> >> >
> >> > >>> idea what the RM is doing - so they shouldn't be making assumptions
> >> >
> >> > about
> >> >
> >> > >>> non-released tags. Once he sends the email though the tag will be
> >> >
> >> > valid.
> >> >
> >> > >>> Sure having the revision number helps but unless the RM completely
> >> >
> >> > screws
> >> >
> >> > >>> up the tag should be sufficient.
> >> > >>>
> >> > >>> Ralph
> >> > >>>
> >> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >> > >>>> Not really, no. The developer may have re-spun it again and be
> >> > >>>> about
> >> >
> >> > to
> >> >
> >> > >>>> email again. You have no idea what you're looking at unless you
> >> > >>>> know
> >> >
> >> > the
> >> >
> >> > >>>> revision. SVN will die off within a decade and this discussion
> >> > >>>> will
> >> > >>>
> >> > >>> become
> >> > >>>
> >> > >>>> critical. Better to figure out how to support proper techniques
> >> > >>>> now,
> >> > >>>
> >> > >>> rather
> >> > >>>
> >> > >>>> than wait until forced to.
> >> > >>>>
> >> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> >> >
> >> > ralph.goers@dslextreme.com
> >> >
> >> > >>>> wrote:
> >> > >>>>> I disagree that the revision is required. I know that the RM is
> >> >
> >> > going
> >> >
> >> > >>> to
> >> > >>>
> >> > >>>>> recreate the tag with each release candidate. Therefore, so long
> >>
> >> as
> >>
> >> > I
> >> >
> >> > >>>>> refetch that tag for every release vote I can be confident that I
> >>
> >> am
> >>
> >> > >>>>> reviewing the release contents.
> >> > >>>>>
> >> > >>>>> Ralph
> >> > >>>>>
> >> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >> > >>>>>> The mission of the ASF is to release software as source, and to
> >> >
> >> > ensure
> >> >
> >> > >>>>>> that the released source is available under the Apache Licence.
> >> > >>>>>>
> >> > >>>>>> Before a release can be approved it must be voted on by the PMC.
> >> > >>>>>> The review process needs to establish that the proposed source
> >> >
> >> > release
> >> >
> >> > >>>>>> meets those aims.
> >> > >>>>>>
> >> > >>>>>> It's all but impossible for reviewers to examine every single
> >> > >>>>>> file
> >> >
> >> > in
> >> >
> >> > >>>>>> a source archive to determine if it meets the criteria.
> >> > >>>>>> And it's not unknown for spurious files to creep into a release
> >> > >>>>>> (perhaps from a stale workspace - are releases always built from
> >> > >>>>>> a
> >> > >>>>>> fresh checkout of the tag?)
> >> > >>>>>>
> >> > >>>>>> However, PMCs are also required to check what is added to the
> >> > >>>>>> SCM
> >> > >>>>>> (SVN/Git) to make sure it meets the required license criteria.
> >> > >>>>>> This is done on an ongoing basis as part of reviewing check-ins
> >>
> >> and
> >>
> >> > >>>>>> accepting new contributions.
> >> > >>>>>> So provided that all the files in the source release are also
> >> >
> >> > present
> >> >
> >> > >>>>>> in SCM, the PMC can be reasonably sure that the source release
> >>
> >> meets
> >>
> >> > >>>>>> the ASF criteria.
> >> > >>>>>>
> >> > >>>>>> Without having the SCM as a database of validated files, there
> >> > >>>>>> are
> >> >
> >> > far
> >> >
> >> > >>>>>> too many files in the average source archive to check
> >>
> >> individually.
> >>
> >> > >>>>>> And how would one check their provenance? The obvious way is to
> >> > >>>>>> compare them with the entries in SCM.
> >> > >>>>>>
> >> > >>>>>> Therefore, I contend that a release vote does not make sense
> >>
> >> without
> >>
> >> > >>>>>> the SCM tag.
> >> > >>>>>> In the case of SVN, since tags are not immutable, the vote
> >> > >>>>>> e-mail
> >> >
> >> > also
> >> >
> >> > >>>>>> needs the revision.
> >> > >>>>>>
> >> > >>>>>> Whether every reviewer actually checks the source archive
> >> > >>>>>> against
> >> >
> >> > SCM
> >> >
> >> > >>>>>> is another matter.
> >> > >>>>>> But if the required SCM information is not present, it would be
> >> > >>>>>> difficult to argue that the RM had provided sufficient
> >> > >>>>>> information
> >> >
> >> > for
> >> >
> >> > >>>>>> a valid review to take place.
> >> >
> >> > ---------------------------------------------------------------------
> >> >
> >> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> > >>>
> >> > >>> -------------------------------------------------------------------
> >> > >>> --
> >> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> > >>
> >> > >> --
> >> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> > >> Java Persistence with Hibernate, Second Edition<
> >> >
> >> > http://www.manning.com/bauer3/>
> >> >
> >> > >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> > >> Spring Batch in Action <http://www.manning.com/templier/>
> >> > >> Blog: http://garygregory.wordpress.com
> >> > >> Home: http://garygregory.com/
> >> > >> Tweet! http://twitter.com/GaryGregory
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> Java Persistence with Hibernate, Second Edition<
> >> http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 26 June 2013 01:04, Chris Graham <ch...@gmail.com> wrote:
> -1
> Except then the poms will point to the wrong place.
Depends how the poms are updated.
>
>
> On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory <ga...@gmail.com>wrote:
>
>> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
>>
>> > It would be a lot better to use RC1 RC2 etc initially, and copy the
>> > successful tag to the GA tag.
>> >
>>
>> +1 ! :)
>>
>> Gary
>>
>>
>> >
>> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>> > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>> failed
>> > release vote instead of deleting them.
>> > >
>> > >
>> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>> > >
>> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>> > ralph.goers@dslextreme.com>wrote:
>> > >>
>> > >>> Again I have to disagree. The release manager will send an email
>> > closing
>> > >>> the prior release. At this point all the prior release artifacts are
>> > junk
>> > >>> even if they still exist. At some point the release manager will
>> > delete
>> > >>> the tag and rerun the release.
>> > >>
>> > >>
>> > >> That's a no-no IMO. Tags that have been voted on should never be
>> > deleted.
>> > >>
>> > >> Gary
>> > >>
>> > >>
>> > >>
>> > >>> At this point the tag is still junk to everyone else because they
>> have
>> > no
>> > >>> idea what the RM is doing - so they shouldn't be making assumptions
>> > about
>> > >>> non-released tags. Once he sends the email though the tag will be
>> > valid.
>> > >>> Sure having the revision number helps but unless the RM completely
>> > screws
>> > >>> up the tag should be sufficient.
>> > >>>
>> > >>> Ralph
>> > >>>
>> > >>>
>> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>> > >>>
>> > >>>> Not really, no. The developer may have re-spun it again and be about
>> > to
>> > >>>> email again. You have no idea what you're looking at unless you know
>> > the
>> > >>>> revision. SVN will die off within a decade and this discussion will
>> > >>> become
>> > >>>> critical. Better to figure out how to support proper techniques now,
>> > >>> rather
>> > >>>> than wait until forced to.
>> > >>>>
>> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>> > ralph.goers@dslextreme.com
>> > >>>> wrote:
>> > >>>>
>> > >>>>> I disagree that the revision is required. I know that the RM is
>> > going
>> > >>> to
>> > >>>>> recreate the tag with each release candidate. Therefore, so long
>> as
>> > I
>> > >>>>> refetch that tag for every release vote I can be confident that I
>> am
>> > >>>>> reviewing the release contents.
>> > >>>>>
>> > >>>>> Ralph
>> > >>>>>
>> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>> > >>>>>
>> > >>>>>> The mission of the ASF is to release software as source, and to
>> > ensure
>> > >>>>>> that the released source is available under the Apache Licence.
>> > >>>>>>
>> > >>>>>> Before a release can be approved it must be voted on by the PMC.
>> > >>>>>> The review process needs to establish that the proposed source
>> > release
>> > >>>>>> meets those aims.
>> > >>>>>>
>> > >>>>>> It's all but impossible for reviewers to examine every single file
>> > in
>> > >>>>>> a source archive to determine if it meets the criteria.
>> > >>>>>> And it's not unknown for spurious files to creep into a release
>> > >>>>>> (perhaps from a stale workspace - are releases always built from a
>> > >>>>>> fresh checkout of the tag?)
>> > >>>>>>
>> > >>>>>> However, PMCs are also required to check what is added to the SCM
>> > >>>>>> (SVN/Git) to make sure it meets the required license criteria.
>> > >>>>>> This is done on an ongoing basis as part of reviewing check-ins
>> and
>> > >>>>>> accepting new contributions.
>> > >>>>>> So provided that all the files in the source release are also
>> > present
>> > >>>>>> in SCM, the PMC can be reasonably sure that the source release
>> meets
>> > >>>>>> the ASF criteria.
>> > >>>>>>
>> > >>>>>> Without having the SCM as a database of validated files, there are
>> > far
>> > >>>>>> too many files in the average source archive to check
>> individually.
>> > >>>>>> And how would one check their provenance? The obvious way is to
>> > >>>>>> compare them with the entries in SCM.
>> > >>>>>>
>> > >>>>>> Therefore, I contend that a release vote does not make sense
>> without
>> > >>>>>> the SCM tag.
>> > >>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
>> > also
>> > >>>>>> needs the revision.
>> > >>>>>>
>> > >>>>>> Whether every reviewer actually checks the source archive against
>> > SCM
>> > >>>>>> is another matter.
>> > >>>>>> But if the required SCM information is not present, it would be
>> > >>>>>> difficult to argue that the RM had provided sufficient information
>> > for
>> > >>>>>> a valid review to take place.
>> > >>>>>>
>> > >>>>>>
>> > ---------------------------------------------------------------------
>> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> > >>>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> ---------------------------------------------------------------------
>> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> > >>>>>
>> > >>>>>
>> > >>>
>> > >>>
>> > >>> ---------------------------------------------------------------------
>> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >> --
>> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > >> Java Persistence with Hibernate, Second Edition<
>> > http://www.manning.com/bauer3/>
>> > >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > >> Spring Batch in Action <http://www.manning.com/templier/>
>> > >> Blog: http://garygregory.wordpress.com
>> > >> Home: http://garygregory.com/
>> > >> Tweet! http://twitter.com/GaryGregory
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
-1
Except then the poms will point to the wrong place.
On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory <ga...@gmail.com>wrote:
> On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
>
> > It would be a lot better to use RC1 RC2 etc initially, and copy the
> > successful tag to the GA tag.
> >
>
> +1 ! :)
>
> Gary
>
>
> >
> > On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
> > > Yeah - I agree with this. I rename them to rc1, rc2, etc after a
> failed
> > release vote instead of deleting them.
> > >
> > >
> > > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> > >
> > >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> > ralph.goers@dslextreme.com>wrote:
> > >>
> > >>> Again I have to disagree. The release manager will send an email
> > closing
> > >>> the prior release. At this point all the prior release artifacts are
> > junk
> > >>> even if they still exist. At some point the release manager will
> > delete
> > >>> the tag and rerun the release.
> > >>
> > >>
> > >> That's a no-no IMO. Tags that have been voted on should never be
> > deleted.
> > >>
> > >> Gary
> > >>
> > >>
> > >>
> > >>> At this point the tag is still junk to everyone else because they
> have
> > no
> > >>> idea what the RM is doing - so they shouldn't be making assumptions
> > about
> > >>> non-released tags. Once he sends the email though the tag will be
> > valid.
> > >>> Sure having the revision number helps but unless the RM completely
> > screws
> > >>> up the tag should be sufficient.
> > >>>
> > >>> Ralph
> > >>>
> > >>>
> > >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> > >>>
> > >>>> Not really, no. The developer may have re-spun it again and be about
> > to
> > >>>> email again. You have no idea what you're looking at unless you know
> > the
> > >>>> revision. SVN will die off within a decade and this discussion will
> > >>> become
> > >>>> critical. Better to figure out how to support proper techniques now,
> > >>> rather
> > >>>> than wait until forced to.
> > >>>>
> > >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> > ralph.goers@dslextreme.com
> > >>>> wrote:
> > >>>>
> > >>>>> I disagree that the revision is required. I know that the RM is
> > going
> > >>> to
> > >>>>> recreate the tag with each release candidate. Therefore, so long
> as
> > I
> > >>>>> refetch that tag for every release vote I can be confident that I
> am
> > >>>>> reviewing the release contents.
> > >>>>>
> > >>>>> Ralph
> > >>>>>
> > >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> > >>>>>
> > >>>>>> The mission of the ASF is to release software as source, and to
> > ensure
> > >>>>>> that the released source is available under the Apache Licence.
> > >>>>>>
> > >>>>>> Before a release can be approved it must be voted on by the PMC.
> > >>>>>> The review process needs to establish that the proposed source
> > release
> > >>>>>> meets those aims.
> > >>>>>>
> > >>>>>> It's all but impossible for reviewers to examine every single file
> > in
> > >>>>>> a source archive to determine if it meets the criteria.
> > >>>>>> And it's not unknown for spurious files to creep into a release
> > >>>>>> (perhaps from a stale workspace - are releases always built from a
> > >>>>>> fresh checkout of the tag?)
> > >>>>>>
> > >>>>>> However, PMCs are also required to check what is added to the SCM
> > >>>>>> (SVN/Git) to make sure it meets the required license criteria.
> > >>>>>> This is done on an ongoing basis as part of reviewing check-ins
> and
> > >>>>>> accepting new contributions.
> > >>>>>> So provided that all the files in the source release are also
> > present
> > >>>>>> in SCM, the PMC can be reasonably sure that the source release
> meets
> > >>>>>> the ASF criteria.
> > >>>>>>
> > >>>>>> Without having the SCM as a database of validated files, there are
> > far
> > >>>>>> too many files in the average source archive to check
> individually.
> > >>>>>> And how would one check their provenance? The obvious way is to
> > >>>>>> compare them with the entries in SCM.
> > >>>>>>
> > >>>>>> Therefore, I contend that a release vote does not make sense
> without
> > >>>>>> the SCM tag.
> > >>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
> > also
> > >>>>>> needs the revision.
> > >>>>>>
> > >>>>>> Whether every reviewer actually checks the source archive against
> > SCM
> > >>>>>> is another matter.
> > >>>>>> But if the required SCM information is not present, it would be
> > >>>>>> difficult to argue that the RM had provided sufficient information
> > for
> > >>>>>> a valid review to take place.
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > >> Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > >> Spring Batch in Action <http://www.manning.com/templier/>
> > >> Blog: http://garygregory.wordpress.com
> > >> Home: http://garygregory.com/
> > >> Tweet! http://twitter.com/GaryGregory
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: Release process updates
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jun 25, 2013 at 7:14 PM, sebb <se...@gmail.com> wrote:
> It would be a lot better to use RC1 RC2 etc initially, and copy the
> successful tag to the GA tag.
>
+1 ! :)
Gary
>
> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
> > Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed
> release vote instead of deleting them.
> >
> >
> > On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >
> >> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> ralph.goers@dslextreme.com>wrote:
> >>
> >>> Again I have to disagree. The release manager will send an email
> closing
> >>> the prior release. At this point all the prior release artifacts are
> junk
> >>> even if they still exist. At some point the release manager will
> delete
> >>> the tag and rerun the release.
> >>
> >>
> >> That's a no-no IMO. Tags that have been voted on should never be
> deleted.
> >>
> >> Gary
> >>
> >>
> >>
> >>> At this point the tag is still junk to everyone else because they have
> no
> >>> idea what the RM is doing - so they shouldn't be making assumptions
> about
> >>> non-released tags. Once he sends the email though the tag will be
> valid.
> >>> Sure having the revision number helps but unless the RM completely
> screws
> >>> up the tag should be sufficient.
> >>>
> >>> Ralph
> >>>
> >>>
> >>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >>>
> >>>> Not really, no. The developer may have re-spun it again and be about
> to
> >>>> email again. You have no idea what you're looking at unless you know
> the
> >>>> revision. SVN will die off within a decade and this discussion will
> >>> become
> >>>> critical. Better to figure out how to support proper techniques now,
> >>> rather
> >>>> than wait until forced to.
> >>>>
> >>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> ralph.goers@dslextreme.com
> >>>> wrote:
> >>>>
> >>>>> I disagree that the revision is required. I know that the RM is
> going
> >>> to
> >>>>> recreate the tag with each release candidate. Therefore, so long as
> I
> >>>>> refetch that tag for every release vote I can be confident that I am
> >>>>> reviewing the release contents.
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >>>>>
> >>>>>> The mission of the ASF is to release software as source, and to
> ensure
> >>>>>> that the released source is available under the Apache Licence.
> >>>>>>
> >>>>>> Before a release can be approved it must be voted on by the PMC.
> >>>>>> The review process needs to establish that the proposed source
> release
> >>>>>> meets those aims.
> >>>>>>
> >>>>>> It's all but impossible for reviewers to examine every single file
> in
> >>>>>> a source archive to determine if it meets the criteria.
> >>>>>> And it's not unknown for spurious files to creep into a release
> >>>>>> (perhaps from a stale workspace - are releases always built from a
> >>>>>> fresh checkout of the tag?)
> >>>>>>
> >>>>>> However, PMCs are also required to check what is added to the SCM
> >>>>>> (SVN/Git) to make sure it meets the required license criteria.
> >>>>>> This is done on an ongoing basis as part of reviewing check-ins and
> >>>>>> accepting new contributions.
> >>>>>> So provided that all the files in the source release are also
> present
> >>>>>> in SCM, the PMC can be reasonably sure that the source release meets
> >>>>>> the ASF criteria.
> >>>>>>
> >>>>>> Without having the SCM as a database of validated files, there are
> far
> >>>>>> too many files in the average source archive to check individually.
> >>>>>> And how would one check their provenance? The obvious way is to
> >>>>>> compare them with the entries in SCM.
> >>>>>>
> >>>>>> Therefore, I contend that a release vote does not make sense without
> >>>>>> the SCM tag.
> >>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
> also
> >>>>>> needs the revision.
> >>>>>>
> >>>>>> Whether every reviewer actually checks the source archive against
> SCM
> >>>>>> is another matter.
> >>>>>> But if the required SCM information is not present, it would be
> >>>>>> difficult to argue that the RM had provided sufficient information
> for
> >>>>>> a valid review to take place.
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
On Fri, Jun 28, 2013 at 9:04 PM, Fred Cooke <fr...@gmail.com> wrote:
> In terms of current SVN usage, the "SVN mv" command is probably a good
> choice, as already discussed. You could argue that a "cp" would be better,
> but this creates wholesale duplication, which is never good.
>
>
The SVN SCM provider uses the svn copy command for the tag operation.
How does this create wholesale duplication?
A svn copy does not duplicate resources server side, so how is this a bad
thing?
-Chris
Re: Release process updates
Posted by Robert Scholte <rf...@apache.org>.
Revisions are not important for the pom.xml and should not be registered
there.
It is only important within the artifact to trace back its origins.
One location would be the Manifest file[1] by the buildnumber-maven-plugin
And you might want to patch the pom.xml which is bundled with the artifact
by most of our packaging plugins[2]
AFAIK when talking about SVN there's no way to refer to a specific
revision with only the URL. With GIT it's even harder.
I'd go for the manifest file.
Robert
[1]
http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html
[2] http://maven.apache.org/shared/maven-archiver/index.html
(addMavenDescriptor)
Op Fri, 28 Jun 2013 14:21:55 +0200 schreef Stephen Connolly
<st...@gmail.com>:
> On Friday, 28 June 2013, Fred Cooke wrote:
>
>> For git the unique hash is sufficient, you don't really need the tag at
>> all, they simply point to the unique hash (or another tag, in a chain).
>> If
>> Git was the SCM of choice, I'd use RCX tags, and then not retag for
>> final,
>> but rather point the final tag AT the last, accepted RC tag.
>>
>> For example
>>
>> artifact-RC1 >> 1234567890ABCDE
>> artifact-RC2 >> ABCDE1234567890
>> artifact-RC3 >> 12345ABCDE67890
>> artifact >> artifact-RC3 (yes this is possible! and is correctly
>> resolved
>> to the hash pointed to by the final chain-link)
>
>
> And how exactly do we bake the hash into the Pom?
>
> We need to know what we are baking into the Pom *before* we can commit
> the
> Pom
>
> So in the GIT world, we need to bake a tag into the Pom as we cannot
> predict the hash.
>
> In the Subversion world, we need to bake a tag without revision into the
> Pom as we cannot predict the revision we will get when we do commit.
>
> I am fine with saying for GIT *votes* the hash of the tag should be
> included in the vote email, but pushing the tag at the time of the vote I
> see as a bad plan (unless we decide to change the tag naming convention)
>
> Subversion does not let us avoid committing the tag, so in that case I am
> fine with saying in the vote email tag@1234342
>
> But I don't see (given the way the version numbering vote went) why we
> need
> to do anything other than the above 1 small change to the vote emails....
> And keep in mind that given that SCM is just a convenience, even that is
> not strictly necessary... It is the -src.tar.gz that we are voting on...
> Everything else is just a convenience
>
>
>>
>> If I were forced (at gun point) to use SVN again, I'd not create real
>> SVN-tags, I'd modify my tooling to either add SVN meta data linking name
>> and revision number and path or do the same in a plain text file(s)
>> somewhere in the repo. The entire SVN cp thing leaves me feeling ill.
>> SVN
>> mv makes me want to cry like a girl. From the help info:
>>
>> Note: this subcommand is equivalent to a 'copy' and 'delete'.
>> >
>>
>> If only file systems were this good! :-p
>>
>> In terms of current SVN usage, the "SVN mv" command is probably a good
>> choice, as already discussed. You could argue that a "cp" would be
>> better,
>> but this creates wholesale duplication, which is never good.
>>
>> Fred.
>>
>> On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
>>
>> > The re-use of tags is a side-issue to this thread, though I'm glad to
>> > see some support for using immutable tags, whatever route is chosen
>> > Please start a new thread to continue that discussion.
>> >
>> > The vote e-mail must have the revision and tag name/trunk URL in it
>> > else it is not complete.
>> >
>> > Just as Maven insists on GAV - where V=version - a unique SVN
>> > coordinate requires the revision and the tree segment selector (e.g.
>> > tag).
>> > I don't know what Git needs - I suppose it may depend on whether
>> > multiple components are part of the same Git instance.
>> >
>> > But whatever - as it stands, the current vote e-mail is
>> > **incomplete**; it does not provide sufficient information for the
>> > candidate to be properly evaluated.
>> > The information needs to be present both for current and historical
>> use.
>> >
>> > On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
>> > > +1 to change our tags convention if it solves this issue by
>> avoiding to
>> > > reuse tag names to give a better visibility from where a release was
>> done
>> > >
>> > >
>> > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
>> > > kristian.rosenvold@gmail.com> wrote:
>> > >
>> > >> This suggestion is much like what we came up with the last time
>> > >> we discussed this - about 3 weeks ago.
>> > >>
>> > >> This behaviour is simple to achieve without a single line
>> > >> of change; the release plugin already asks for a SCM tag name
>> > >> distinct from the version number. (we *could* add some kind
>> > >> of support for an explicit convention, we could even add a
>> scm-lookup
>> > >> to auto-roll forward on subsequent takes).
>> > >>
>> > >> Now I've been trying to think if there's a sensible convention
>> > >> that could be established that would allow us to
>> > >> simply *keep* the tag name of the accepted version
>> > >> without re-pushing another tag after release (and, since the tag
>> > >> name can be etched into the pom of the released artifact, there
>> > >> should be no real reason for confusion).
>> > >>
>> > >> I've been thinking about a *tagging* convention along the lines
>> > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
>> > >> maven-xx-plugin-2.3.2#3..."
>> > >>
>> > >> Effectively we would delete #1 and #2 and keep the #3 tag, since
>> this
>> > >> vote passed on take 3.
>> > >>
>> > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
>> > >> released 2.3.2 version.
>> > >>
>> > >> This is mostly a policy change on tag naming, we could implement
>> this
>> > >> without a line
>> > >> of code change. Since both svn and git essentially have flawed tag
>> > >> handling it makes sense to do a change like this.
>> > >>
>> > >> Kristian
>> > >>
>> > >> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>> > >> > Can you provide the steps required to get the release plugin to
>> work
>> > >> this way?
>> > >> >
>> > >> > Ralph
>> > >> >
>> > >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>> > >> >
>> > >> >> Hello,
>> > >> >>
>> > >> >> this seems to be the most popular discussion, so another 2
>> cents:
>> > >> >> - Today I read the man page of git-tag again.
>> > >> >> - It states very clearly you should never reuse tags, because
>> unlike
>> > is
>> > >> the
>> > >> >> case with subversion, once a git tag is out in the wild (and
>> pushing
>> > to
>> > >> >> git-wip is the jungle here), everyone who has fetched the tag
>> would
>> > >> have to
>> > >> >> delete it *manually* from her copy, otherwise it will point to
>> the
>> > wrong
>> > >> >> hash eternally.
>> > >> >>
>> > >> >> Another approach:
>> > >> >> - Always attach the rc-number to the tagname, e.g.
>> maven-foo-2.16rc1,
>> > >> but
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Hello,
I think svn/git are most interesting, as AFAIK all core-plugins reside in
these SCMs :-).[1]
Being able to easily review the code diff between several takes or releases
has a value of it's own IMO. With websvn, gitweb or github e.g., it is
quite trivial to create a link which shows the complete diff/patch between
two tags/branches. To include such a link in the vote mail would be great
(fisheye/viewcvs do *not* have this ability unfortunately), at least a
command line reproducing the patch could help.
It is much more effort, when every reviewer does this work on her own, let
alone when tags are mutable as they are in the current process, where you
have to scan the log for the correct revisions/hashes.
Regards Mirko
[1] People still forced to use CVS or Sourcesafe should probably just look
for a new job or when they are the ones responsible for this a good shrink
;-).
--
Sent from my mobile
On Jun 29, 2013 3:30 AM, "Chris Graham" <ch...@gmail.com> wrote:
> Moreover, the discussion is very SVN/GIT centric. The release plugin and
> continuum (as far as I know) are the primary users of the SCM api. The
> entire scm api is an abstraction layer that is very cvs/svn centric (for
> historical reasons) but an abstraction layer all the same, and abstraction
> layers tend to the lowest common denominator (they have too).
>
> So as the "Do we respin version nos/tags" thread summarized, what is good
> practice for one may not be for another. So, just like life, it's full of
> comprimises.
>
> If we included AccuRev, ClearCase and Jazz, for example, into this thread,
> then we'd have (probably) an entirely different view, based around what
> those SCM's either could or could not do. (For example, Jazz can not delete
> it's tags from the cli, only from the full Eclipse GUI or Web clients - so
> that it not automatable. But the svn provider does not delete tags either,
> so there may always be some manual cleanup involved).
>
> As it stands, I don't see the need to include the rev no in the email, as
> the tag that has been created, that we are voting on, has it's own revision
> no, and is easily found, as is the path.
>
> If the vote fails, the necessary changes are made, the same tag, with a
> different revision no is used. If the vote passes, the tag remains
> permanent.
>
> I see little value in documenting the failed releases. You will always be
> able to trawl through these email lists and svn history to retreive the
> intermediate details, should you ever need them.
>
> -Chris
>
>
>
> On Fri, Jun 28, 2013 at 10:21 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On Friday, 28 June 2013, Fred Cooke wrote:
> >
> > > For git the unique hash is sufficient, you don't really need the tag at
> > > all, they simply point to the unique hash (or another tag, in a chain).
> > If
> > > Git was the SCM of choice, I'd use RCX tags, and then not retag for
> > final,
> > > but rather point the final tag AT the last, accepted RC tag.
> > >
> > > For example
> > >
> > > artifact-RC1 >> 1234567890ABCDE
> > > artifact-RC2 >> ABCDE1234567890
> > > artifact-RC3 >> 12345ABCDE67890
> > > artifact >> artifact-RC3 (yes this is possible! and is correctly
> resolved
> > > to the hash pointed to by the final chain-link)
> >
> >
> > And how exactly do we bake the hash into the Pom?
> >
> > We need to know what we are baking into the Pom *before* we can commit
> the
> > Pom
> >
> > So in the GIT world, we need to bake a tag into the Pom as we cannot
> > predict the hash.
> >
> > In the Subversion world, we need to bake a tag without revision into the
> > Pom as we cannot predict the revision we will get when we do commit.
> >
> > I am fine with saying for GIT *votes* the hash of the tag should be
> > included in the vote email, but pushing the tag at the time of the vote I
> > see as a bad plan (unless we decide to change the tag naming convention)
> >
> > Subversion does not let us avoid committing the tag, so in that case I am
> > fine with saying in the vote email tag@1234342
> >
> > But I don't see (given the way the version numbering vote went) why we
> need
> > to do anything other than the above 1 small change to the vote emails....
> > And keep in mind that given that SCM is just a convenience, even that is
> > not strictly necessary... It is the -src.tar.gz that we are voting on...
> > Everything else is just a convenience
> >
> >
> > >
> > > If I were forced (at gun point) to use SVN again, I'd not create real
> > > SVN-tags, I'd modify my tooling to either add SVN meta data linking
> name
> > > and revision number and path or do the same in a plain text file(s)
> > > somewhere in the repo. The entire SVN cp thing leaves me feeling ill.
> SVN
> > > mv makes me want to cry like a girl. From the help info:
> > >
> > > Note: this subcommand is equivalent to a 'copy' and 'delete'.
> > > >
> > >
> > > If only file systems were this good! :-p
> > >
> > > In terms of current SVN usage, the "SVN mv" command is probably a good
> > > choice, as already discussed. You could argue that a "cp" would be
> > better,
> > > but this creates wholesale duplication, which is never good.
> > >
> > > Fred.
> > >
> > > On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
> > >
> > > > The re-use of tags is a side-issue to this thread, though I'm glad to
> > > > see some support for using immutable tags, whatever route is chosen
> > > > Please start a new thread to continue that discussion.
> > > >
> > > > The vote e-mail must have the revision and tag name/trunk URL in it
> > > > else it is not complete.
> > > >
> > > > Just as Maven insists on GAV - where V=version - a unique SVN
> > > > coordinate requires the revision and the tree segment selector (e.g.
> > > > tag).
> > > > I don't know what Git needs - I suppose it may depend on whether
> > > > multiple components are part of the same Git instance.
> > > >
> > > > But whatever - as it stands, the current vote e-mail is
> > > > **incomplete**; it does not provide sufficient information for the
> > > > candidate to be properly evaluated.
> > > > The information needs to be present both for current and historical
> > use.
> > > >
> > > > On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
> > > > > +1 to change our tags convention if it solves this issue by
> avoiding
> > to
> > > > > reuse tag names to give a better visibility from where a release
> was
> > > done
> > > > >
> > > > >
> > > > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
> > > > > kristian.rosenvold@gmail.com> wrote:
> > > > >
> > > > >> This suggestion is much like what we came up with the last time
> > > > >> we discussed this - about 3 weeks ago.
> > > > >>
> > > > >> This behaviour is simple to achieve without a single line
> > > > >> of change; the release plugin already asks for a SCM tag name
> > > > >> distinct from the version number. (we *could* add some kind
> > > > >> of support for an explicit convention, we could even add a
> > scm-lookup
> > > > >> to auto-roll forward on subsequent takes).
> > > > >>
> > > > >> Now I've been trying to think if there's a sensible convention
> > > > >> that could be established that would allow us to
> > > > >> simply *keep* the tag name of the accepted version
> > > > >> without re-pushing another tag after release (and, since the tag
> > > > >> name can be etched into the pom of the released artifact, there
> > > > >> should be no real reason for confusion).
> > > > >>
> > > > >> I've been thinking about a *tagging* convention along the lines
> > > > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> > > > >> maven-xx-plugin-2.3.2#3..."
> > > > >>
> > > > >> Effectively we would delete #1 and #2 and keep the #3 tag, since
> > this
> > > > >> vote passed on take 3.
> > > > >>
> > > > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of
> the
> > > > >> released 2.3.2 version.
> > > > >>
> > > > >> This is mostly a policy change on tag naming, we could implement
> > this
> > > > >> without a line
> > > > >> of code change. Since both svn and git essentially have flawed tag
> > > > >> handling it makes sense to do a change like this.
> > > > >>
> > > > >> Kristian
> > > > >>
> > > > >> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> > > > >> > Can you provide the steps required to get the release plugin to
> > work
> > > > >> this way?
> > > > >> >
> > > > >> > Ralph
> > > > >> >
> > > > >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> > > > >> >
> > > > >> >> Hello,
> > > > >> >>
> > > > >> >> this seems to be the most popular discussion, so another 2
> cents:
> > > > >> >> - Today I read the man page of git-tag again.
> > > > >> >> - It states very clearly you should never reuse tags, because
> > > unlike
> > > > is
> > > > >> the
> > > > >> >> case with subversion, once a git tag is out in the wild (and
> > > pushing
> > > > to
> > > > >> >> git-wip is the jungle here), everyone who has fetched the tag
> > would
> > > > >> have to
> > > > >> >> delete it *manually* from her copy, otherwise it will point to
> > the
> > > > wrong
> > > > >> >> hash eternally.
> > > > >> >>
> > > > >> >> Another approach:
> > > > >> >> - Always attach the rc-number to the tagname, e.g.
> > > maven-foo-2.16rc1,
> > > > >> but
> > >
> >
> >
> > --
> > Sent from my phone
> >
>
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
Moreover, the discussion is very SVN/GIT centric. The release plugin and
continuum (as far as I know) are the primary users of the SCM api. The
entire scm api is an abstraction layer that is very cvs/svn centric (for
historical reasons) but an abstraction layer all the same, and abstraction
layers tend to the lowest common denominator (they have too).
So as the "Do we respin version nos/tags" thread summarized, what is good
practice for one may not be for another. So, just like life, it's full of
comprimises.
If we included AccuRev, ClearCase and Jazz, for example, into this thread,
then we'd have (probably) an entirely different view, based around what
those SCM's either could or could not do. (For example, Jazz can not delete
it's tags from the cli, only from the full Eclipse GUI or Web clients - so
that it not automatable. But the svn provider does not delete tags either,
so there may always be some manual cleanup involved).
As it stands, I don't see the need to include the rev no in the email, as
the tag that has been created, that we are voting on, has it's own revision
no, and is easily found, as is the path.
If the vote fails, the necessary changes are made, the same tag, with a
different revision no is used. If the vote passes, the tag remains
permanent.
I see little value in documenting the failed releases. You will always be
able to trawl through these email lists and svn history to retreive the
intermediate details, should you ever need them.
-Chris
On Fri, Jun 28, 2013 at 10:21 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On Friday, 28 June 2013, Fred Cooke wrote:
>
> > For git the unique hash is sufficient, you don't really need the tag at
> > all, they simply point to the unique hash (or another tag, in a chain).
> If
> > Git was the SCM of choice, I'd use RCX tags, and then not retag for
> final,
> > but rather point the final tag AT the last, accepted RC tag.
> >
> > For example
> >
> > artifact-RC1 >> 1234567890ABCDE
> > artifact-RC2 >> ABCDE1234567890
> > artifact-RC3 >> 12345ABCDE67890
> > artifact >> artifact-RC3 (yes this is possible! and is correctly resolved
> > to the hash pointed to by the final chain-link)
>
>
> And how exactly do we bake the hash into the Pom?
>
> We need to know what we are baking into the Pom *before* we can commit the
> Pom
>
> So in the GIT world, we need to bake a tag into the Pom as we cannot
> predict the hash.
>
> In the Subversion world, we need to bake a tag without revision into the
> Pom as we cannot predict the revision we will get when we do commit.
>
> I am fine with saying for GIT *votes* the hash of the tag should be
> included in the vote email, but pushing the tag at the time of the vote I
> see as a bad plan (unless we decide to change the tag naming convention)
>
> Subversion does not let us avoid committing the tag, so in that case I am
> fine with saying in the vote email tag@1234342
>
> But I don't see (given the way the version numbering vote went) why we need
> to do anything other than the above 1 small change to the vote emails....
> And keep in mind that given that SCM is just a convenience, even that is
> not strictly necessary... It is the -src.tar.gz that we are voting on...
> Everything else is just a convenience
>
>
> >
> > If I were forced (at gun point) to use SVN again, I'd not create real
> > SVN-tags, I'd modify my tooling to either add SVN meta data linking name
> > and revision number and path or do the same in a plain text file(s)
> > somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN
> > mv makes me want to cry like a girl. From the help info:
> >
> > Note: this subcommand is equivalent to a 'copy' and 'delete'.
> > >
> >
> > If only file systems were this good! :-p
> >
> > In terms of current SVN usage, the "SVN mv" command is probably a good
> > choice, as already discussed. You could argue that a "cp" would be
> better,
> > but this creates wholesale duplication, which is never good.
> >
> > Fred.
> >
> > On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
> >
> > > The re-use of tags is a side-issue to this thread, though I'm glad to
> > > see some support for using immutable tags, whatever route is chosen
> > > Please start a new thread to continue that discussion.
> > >
> > > The vote e-mail must have the revision and tag name/trunk URL in it
> > > else it is not complete.
> > >
> > > Just as Maven insists on GAV - where V=version - a unique SVN
> > > coordinate requires the revision and the tree segment selector (e.g.
> > > tag).
> > > I don't know what Git needs - I suppose it may depend on whether
> > > multiple components are part of the same Git instance.
> > >
> > > But whatever - as it stands, the current vote e-mail is
> > > **incomplete**; it does not provide sufficient information for the
> > > candidate to be properly evaluated.
> > > The information needs to be present both for current and historical
> use.
> > >
> > > On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
> > > > +1 to change our tags convention if it solves this issue by avoiding
> to
> > > > reuse tag names to give a better visibility from where a release was
> > done
> > > >
> > > >
> > > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
> > > > kristian.rosenvold@gmail.com> wrote:
> > > >
> > > >> This suggestion is much like what we came up with the last time
> > > >> we discussed this - about 3 weeks ago.
> > > >>
> > > >> This behaviour is simple to achieve without a single line
> > > >> of change; the release plugin already asks for a SCM tag name
> > > >> distinct from the version number. (we *could* add some kind
> > > >> of support for an explicit convention, we could even add a
> scm-lookup
> > > >> to auto-roll forward on subsequent takes).
> > > >>
> > > >> Now I've been trying to think if there's a sensible convention
> > > >> that could be established that would allow us to
> > > >> simply *keep* the tag name of the accepted version
> > > >> without re-pushing another tag after release (and, since the tag
> > > >> name can be etched into the pom of the released artifact, there
> > > >> should be no real reason for confusion).
> > > >>
> > > >> I've been thinking about a *tagging* convention along the lines
> > > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> > > >> maven-xx-plugin-2.3.2#3..."
> > > >>
> > > >> Effectively we would delete #1 and #2 and keep the #3 tag, since
> this
> > > >> vote passed on take 3.
> > > >>
> > > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
> > > >> released 2.3.2 version.
> > > >>
> > > >> This is mostly a policy change on tag naming, we could implement
> this
> > > >> without a line
> > > >> of code change. Since both svn and git essentially have flawed tag
> > > >> handling it makes sense to do a change like this.
> > > >>
> > > >> Kristian
> > > >>
> > > >> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> > > >> > Can you provide the steps required to get the release plugin to
> work
> > > >> this way?
> > > >> >
> > > >> > Ralph
> > > >> >
> > > >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> > > >> >
> > > >> >> Hello,
> > > >> >>
> > > >> >> this seems to be the most popular discussion, so another 2 cents:
> > > >> >> - Today I read the man page of git-tag again.
> > > >> >> - It states very clearly you should never reuse tags, because
> > unlike
> > > is
> > > >> the
> > > >> >> case with subversion, once a git tag is out in the wild (and
> > pushing
> > > to
> > > >> >> git-wip is the jungle here), everyone who has fetched the tag
> would
> > > >> have to
> > > >> >> delete it *manually* from her copy, otherwise it will point to
> the
> > > wrong
> > > >> >> hash eternally.
> > > >> >>
> > > >> >> Another approach:
> > > >> >> - Always attach the rc-number to the tagname, e.g.
> > maven-foo-2.16rc1,
> > > >> but
> >
>
>
> --
> Sent from my phone
>
Re: Release process updates
Posted by Baptiste MATHUS <bm...@batmat.net>.
2013/6/28 Fred Cooke <fr...@gmail.com>
> Someone else already covered that. The tag can live forever as it always
> was in the POM. In the SVN version you can either lie before or after, in
> the Git version you can use final or RC and they'll end up pointing at the
> same commit. Having said that, I never understood why that was done anyway.
> My poms don't even have the tag XML tag in them and the release plugin
> rudely inserts it and then removes it again (and butchers the formatting in
> the process...). It'd be nice to turn that off, though that's another
> discussion for another day.
>
> This "SCM is convenience" comment keeps popping up. I strongly disagree.
>
> You have two requirements:
>
> 1) Keep ASF legal people happy
>
*Legal*, that's only basis and the thing Stephen reminds.
Sure, no developers would work without a scm today, but Apache Foundation
does not require the scm revision, or even a scm be used.
> 2) Produce quality software artifacts
>
> SCM is absolutely essential for the second goal.
>
+1, sure.
>
> Are you saying that Uwe and the Lucene project are violating ASF protocol
>
I don't think they are. As I don't think the Maven is violating any ASF
rule either.
> by voting on the SCM revision and only then building/tagging/etc? SCM (even
> SVN) gives you a fundamentally solid and reliable way to KNOW what's there.
> Voting on a hash or rev number and then building from it afterward seems
> like a good move and would save a lot of drama. In terms of providing
> temporary artifacts to judge that SCM hash/rev by, that's what SNAPSHOT
> builds are for...
>
I don't think there has to be that drama. I suppose the scm revision/git
hash could be included in the vote mails. And carry on.
-- Baptiste
Re: Release process updates
Posted by Fred Cooke <fr...@gmail.com>.
Someone else already covered that. The tag can live forever as it always
was in the POM. In the SVN version you can either lie before or after, in
the Git version you can use final or RC and they'll end up pointing at the
same commit. Having said that, I never understood why that was done anyway.
My poms don't even have the tag XML tag in them and the release plugin
rudely inserts it and then removes it again (and butchers the formatting in
the process...). It'd be nice to turn that off, though that's another
discussion for another day.
This "SCM is convenience" comment keeps popping up. I strongly disagree.
You have two requirements:
1) Keep ASF legal people happy
2) Produce quality software artifacts
SCM is absolutely essential for the second goal.
Are you saying that Uwe and the Lucene project are violating ASF protocol
by voting on the SCM revision and only then building/tagging/etc? SCM (even
SVN) gives you a fundamentally solid and reliable way to KNOW what's there.
Voting on a hash or rev number and then building from it afterward seems
like a good move and would save a lot of drama. In terms of providing
temporary artifacts to judge that SCM hash/rev by, that's what SNAPSHOT
builds are for...
Fred.
On Fri, Jun 28, 2013 at 2:21 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On Friday, 28 June 2013, Fred Cooke wrote:
>
> > For git the unique hash is sufficient, you don't really need the tag at
> > all, they simply point to the unique hash (or another tag, in a chain).
> If
> > Git was the SCM of choice, I'd use RCX tags, and then not retag for
> final,
> > but rather point the final tag AT the last, accepted RC tag.
> >
> > For example
> >
> > artifact-RC1 >> 1234567890ABCDE
> > artifact-RC2 >> ABCDE1234567890
> > artifact-RC3 >> 12345ABCDE67890
> > artifact >> artifact-RC3 (yes this is possible! and is correctly resolved
> > to the hash pointed to by the final chain-link)
>
>
> And how exactly do we bake the hash into the Pom?
>
> We need to know what we are baking into the Pom *before* we can commit the
> Pom
>
> So in the GIT world, we need to bake a tag into the Pom as we cannot
> predict the hash.
>
> In the Subversion world, we need to bake a tag without revision into the
> Pom as we cannot predict the revision we will get when we do commit.
>
> I am fine with saying for GIT *votes* the hash of the tag should be
> included in the vote email, but pushing the tag at the time of the vote I
> see as a bad plan (unless we decide to change the tag naming convention)
>
> Subversion does not let us avoid committing the tag, so in that case I am
> fine with saying in the vote email tag@1234342
>
> But I don't see (given the way the version numbering vote went) why we need
> to do anything other than the above 1 small change to the vote emails....
> And keep in mind that given that SCM is just a convenience, even that is
> not strictly necessary... It is the -src.tar.gz that we are voting on...
> Everything else is just a convenience
>
>
> >
> > If I were forced (at gun point) to use SVN again, I'd not create real
> > SVN-tags, I'd modify my tooling to either add SVN meta data linking name
> > and revision number and path or do the same in a plain text file(s)
> > somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN
> > mv makes me want to cry like a girl. From the help info:
> >
> > Note: this subcommand is equivalent to a 'copy' and 'delete'.
> > >
> >
> > If only file systems were this good! :-p
> >
> > In terms of current SVN usage, the "SVN mv" command is probably a good
> > choice, as already discussed. You could argue that a "cp" would be
> better,
> > but this creates wholesale duplication, which is never good.
> >
> > Fred.
> >
> > On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
> >
> > > The re-use of tags is a side-issue to this thread, though I'm glad to
> > > see some support for using immutable tags, whatever route is chosen
> > > Please start a new thread to continue that discussion.
> > >
> > > The vote e-mail must have the revision and tag name/trunk URL in it
> > > else it is not complete.
> > >
> > > Just as Maven insists on GAV - where V=version - a unique SVN
> > > coordinate requires the revision and the tree segment selector (e.g.
> > > tag).
> > > I don't know what Git needs - I suppose it may depend on whether
> > > multiple components are part of the same Git instance.
> > >
> > > But whatever - as it stands, the current vote e-mail is
> > > **incomplete**; it does not provide sufficient information for the
> > > candidate to be properly evaluated.
> > > The information needs to be present both for current and historical
> use.
> > >
> > > On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
> > > > +1 to change our tags convention if it solves this issue by avoiding
> to
> > > > reuse tag names to give a better visibility from where a release was
> > done
> > > >
> > > >
> > > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
> > > > kristian.rosenvold@gmail.com> wrote:
> > > >
> > > >> This suggestion is much like what we came up with the last time
> > > >> we discussed this - about 3 weeks ago.
> > > >>
> > > >> This behaviour is simple to achieve without a single line
> > > >> of change; the release plugin already asks for a SCM tag name
> > > >> distinct from the version number. (we *could* add some kind
> > > >> of support for an explicit convention, we could even add a
> scm-lookup
> > > >> to auto-roll forward on subsequent takes).
> > > >>
> > > >> Now I've been trying to think if there's a sensible convention
> > > >> that could be established that would allow us to
> > > >> simply *keep* the tag name of the accepted version
> > > >> without re-pushing another tag after release (and, since the tag
> > > >> name can be etched into the pom of the released artifact, there
> > > >> should be no real reason for confusion).
> > > >>
> > > >> I've been thinking about a *tagging* convention along the lines
> > > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> > > >> maven-xx-plugin-2.3.2#3..."
> > > >>
> > > >> Effectively we would delete #1 and #2 and keep the #3 tag, since
> this
> > > >> vote passed on take 3.
> > > >>
> > > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
> > > >> released 2.3.2 version.
> > > >>
> > > >> This is mostly a policy change on tag naming, we could implement
> this
> > > >> without a line
> > > >> of code change. Since both svn and git essentially have flawed tag
> > > >> handling it makes sense to do a change like this.
> > > >>
> > > >> Kristian
> > > >>
> > > >> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> > > >> > Can you provide the steps required to get the release plugin to
> work
> > > >> this way?
> > > >> >
> > > >> > Ralph
> > > >> >
> > > >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> > > >> >
> > > >> >> Hello,
> > > >> >>
> > > >> >> this seems to be the most popular discussion, so another 2 cents:
> > > >> >> - Today I read the man page of git-tag again.
> > > >> >> - It states very clearly you should never reuse tags, because
> > unlike
> > > is
> > > >> the
> > > >> >> case with subversion, once a git tag is out in the wild (and
> > pushing
> > > to
> > > >> >> git-wip is the jungle here), everyone who has fetched the tag
> would
> > > >> have to
> > > >> >> delete it *manually* from her copy, otherwise it will point to
> the
> > > wrong
> > > >> >> hash eternally.
> > > >> >>
> > > >> >> Another approach:
> > > >> >> - Always attach the rc-number to the tagname, e.g.
> > maven-foo-2.16rc1,
> > > >> but
> >
>
>
> --
> Sent from my phone
>
Re: Release process updates
Posted by Stephen Connolly <st...@gmail.com>.
On Friday, 28 June 2013, Fred Cooke wrote:
> For git the unique hash is sufficient, you don't really need the tag at
> all, they simply point to the unique hash (or another tag, in a chain). If
> Git was the SCM of choice, I'd use RCX tags, and then not retag for final,
> but rather point the final tag AT the last, accepted RC tag.
>
> For example
>
> artifact-RC1 >> 1234567890ABCDE
> artifact-RC2 >> ABCDE1234567890
> artifact-RC3 >> 12345ABCDE67890
> artifact >> artifact-RC3 (yes this is possible! and is correctly resolved
> to the hash pointed to by the final chain-link)
And how exactly do we bake the hash into the Pom?
We need to know what we are baking into the Pom *before* we can commit the
Pom
So in the GIT world, we need to bake a tag into the Pom as we cannot
predict the hash.
In the Subversion world, we need to bake a tag without revision into the
Pom as we cannot predict the revision we will get when we do commit.
I am fine with saying for GIT *votes* the hash of the tag should be
included in the vote email, but pushing the tag at the time of the vote I
see as a bad plan (unless we decide to change the tag naming convention)
Subversion does not let us avoid committing the tag, so in that case I am
fine with saying in the vote email tag@1234342
But I don't see (given the way the version numbering vote went) why we need
to do anything other than the above 1 small change to the vote emails....
And keep in mind that given that SCM is just a convenience, even that is
not strictly necessary... It is the -src.tar.gz that we are voting on...
Everything else is just a convenience
>
> If I were forced (at gun point) to use SVN again, I'd not create real
> SVN-tags, I'd modify my tooling to either add SVN meta data linking name
> and revision number and path or do the same in a plain text file(s)
> somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN
> mv makes me want to cry like a girl. From the help info:
>
> Note: this subcommand is equivalent to a 'copy' and 'delete'.
> >
>
> If only file systems were this good! :-p
>
> In terms of current SVN usage, the "SVN mv" command is probably a good
> choice, as already discussed. You could argue that a "cp" would be better,
> but this creates wholesale duplication, which is never good.
>
> Fred.
>
> On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
>
> > The re-use of tags is a side-issue to this thread, though I'm glad to
> > see some support for using immutable tags, whatever route is chosen
> > Please start a new thread to continue that discussion.
> >
> > The vote e-mail must have the revision and tag name/trunk URL in it
> > else it is not complete.
> >
> > Just as Maven insists on GAV - where V=version - a unique SVN
> > coordinate requires the revision and the tree segment selector (e.g.
> > tag).
> > I don't know what Git needs - I suppose it may depend on whether
> > multiple components are part of the same Git instance.
> >
> > But whatever - as it stands, the current vote e-mail is
> > **incomplete**; it does not provide sufficient information for the
> > candidate to be properly evaluated.
> > The information needs to be present both for current and historical use.
> >
> > On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
> > > +1 to change our tags convention if it solves this issue by avoiding to
> > > reuse tag names to give a better visibility from where a release was
> done
> > >
> > >
> > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
> > > kristian.rosenvold@gmail.com> wrote:
> > >
> > >> This suggestion is much like what we came up with the last time
> > >> we discussed this - about 3 weeks ago.
> > >>
> > >> This behaviour is simple to achieve without a single line
> > >> of change; the release plugin already asks for a SCM tag name
> > >> distinct from the version number. (we *could* add some kind
> > >> of support for an explicit convention, we could even add a scm-lookup
> > >> to auto-roll forward on subsequent takes).
> > >>
> > >> Now I've been trying to think if there's a sensible convention
> > >> that could be established that would allow us to
> > >> simply *keep* the tag name of the accepted version
> > >> without re-pushing another tag after release (and, since the tag
> > >> name can be etched into the pom of the released artifact, there
> > >> should be no real reason for confusion).
> > >>
> > >> I've been thinking about a *tagging* convention along the lines
> > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> > >> maven-xx-plugin-2.3.2#3..."
> > >>
> > >> Effectively we would delete #1 and #2 and keep the #3 tag, since this
> > >> vote passed on take 3.
> > >>
> > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
> > >> released 2.3.2 version.
> > >>
> > >> This is mostly a policy change on tag naming, we could implement this
> > >> without a line
> > >> of code change. Since both svn and git essentially have flawed tag
> > >> handling it makes sense to do a change like this.
> > >>
> > >> Kristian
> > >>
> > >> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> > >> > Can you provide the steps required to get the release plugin to work
> > >> this way?
> > >> >
> > >> > Ralph
> > >> >
> > >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> > >> >
> > >> >> Hello,
> > >> >>
> > >> >> this seems to be the most popular discussion, so another 2 cents:
> > >> >> - Today I read the man page of git-tag again.
> > >> >> - It states very clearly you should never reuse tags, because
> unlike
> > is
> > >> the
> > >> >> case with subversion, once a git tag is out in the wild (and
> pushing
> > to
> > >> >> git-wip is the jungle here), everyone who has fetched the tag would
> > >> have to
> > >> >> delete it *manually* from her copy, otherwise it will point to the
> > wrong
> > >> >> hash eternally.
> > >> >>
> > >> >> Another approach:
> > >> >> - Always attach the rc-number to the tagname, e.g.
> maven-foo-2.16rc1,
> > >> but
>
--
Sent from my phone
Re: Release process updates
Posted by Fred Cooke <fr...@gmail.com>.
@ Chris Graham email 1
If you had, you'd have seen that the release plugin
> uses a svn copy to create the tag. A tag, in this instance is a lebel, or
> sym link for a revision.
>
These two sentences together are pure comedy gold. The second one is purely
false. A tag in SVN is nothing more than a directory/path and revision as
sebb keeps trying, unsuccessfully, to explain to you.
Furthermore, his comment which you say "makes no sense" makes perfect sense
and is accurate.
@ Chris Graham email 2
Two directories/paths in SVN with an absolutely identical set of files is
absolutely a wholesale duplication. If you can not see this you are blind,
my friend.
@ Gary Gregory email
I beg to differ. From the link provided:
"Moves are represented within the working copy as a copy and a delete which
are linked to one another."
"Moves are recorded as such only within the working copy. The link between
the copy and the delete is established only when a local move operation is
performed, and is lost upon commit."
This is an architectural limitation of SVN, and it is what it is. The
primary SVN authors don't even use the system anymore. That's a bit of a
clue.
Fred.
On Fri, Jun 28, 2013 at 1:42 PM, Gary Gregory <ga...@gmail.com>wrote:
> On Jun 28, 2013, at 7:05, Fred Cooke <fr...@gmail.com> wrote:
>
> For git the unique hash is sufficient, you don't really need the tag at
> all, they simply point to the unique hash (or another tag, in a chain). If
> Git was the SCM of choice, I'd use RCX tags, and then not retag for final,
> but rather point the final tag AT the last, accepted RC tag.
>
> For example
>
> artifact-RC1 >> 1234567890ABCDE
> artifact-RC2 >> ABCDE1234567890
> artifact-RC3 >> 12345ABCDE67890
> artifact >> artifact-RC3 (yes this is possible! and is correctly resolved
> to the hash pointed to by the final chain-link)
>
> If I were forced (at gun point) to use SVN again, I'd not create real
> SVN-tags, I'd modify my tooling to either add SVN meta data linking name
> and revision number and path or do the same in a plain text file(s)
> somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN
> mv makes me want to cry like a girl. From the help info:
>
> Note: this subcommand is equivalent to a 'copy' and 'delete'.
>
>
> Not so anymore, see
> http://subversion.apache.org/docs/release-notes/1.8.html
>
> Gary
>
>
>
> If only file systems were this good! :-p
>
> In terms of current SVN usage, the "SVN mv" command is probably a good
> choice, as already discussed. You could argue that a "cp" would be better,
> but this creates wholesale duplication, which is never good.
>
> Fred.
>
> On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
>
> The re-use of tags is a side-issue to this thread, though I'm glad to
>
> see some support for using immutable tags, whatever route is chosen
>
> Please start a new thread to continue that discussion.
>
>
> The vote e-mail must have the revision and tag name/trunk URL in it
>
> else it is not complete.
>
>
> Just as Maven insists on GAV - where V=version - a unique SVN
>
> coordinate requires the revision and the tree segment selector (e.g.
>
> tag).
>
> I don't know what Git needs - I suppose it may depend on whether
>
> multiple components are part of the same Git instance.
>
>
> But whatever - as it stands, the current vote e-mail is
>
> **incomplete**; it does not provide sufficient information for the
>
> candidate to be properly evaluated.
>
> The information needs to be present both for current and historical use.
>
>
> On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
>
> +1 to change our tags convention if it solves this issue by avoiding to
>
> reuse tag names to give a better visibility from where a release was done
>
>
>
> On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
>
> kristian.rosenvold@gmail.com> wrote:
>
>
> This suggestion is much like what we came up with the last time
>
> we discussed this - about 3 weeks ago.
>
>
> This behaviour is simple to achieve without a single line
>
> of change; the release plugin already asks for a SCM tag name
>
> distinct from the version number. (we *could* add some kind
>
> of support for an explicit convention, we could even add a scm-lookup
>
> to auto-roll forward on subsequent takes).
>
>
> Now I've been trying to think if there's a sensible convention
>
> that could be established that would allow us to
>
> simply *keep* the tag name of the accepted version
>
> without re-pushing another tag after release (and, since the tag
>
> name can be etched into the pom of the released artifact, there
>
> should be no real reason for confusion).
>
>
> I've been thinking about a *tagging* convention along the lines
>
> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
>
> maven-xx-plugin-2.3.2#3..."
>
>
> Effectively we would delete #1 and #2 and keep the #3 tag, since this
>
> vote passed on take 3.
>
>
> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
>
> released 2.3.2 version.
>
>
> This is mostly a policy change on tag naming, we could implement this
>
> without a line
>
> of code change. Since both svn and git essentially have flawed tag
>
> handling it makes sense to do a change like this.
>
>
> Kristian
>
>
> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>
> Can you provide the steps required to get the release plugin to work
>
> this way?
>
>
> Ralph
>
>
> On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>
>
> Hello,
>
>
> this seems to be the most popular discussion, so another 2 cents:
>
> - Today I read the man page of git-tag again.
>
> - It states very clearly you should never reuse tags, because unlike
>
> is
>
> the
>
> case with subversion, once a git tag is out in the wild (and pushing
>
> to
>
> git-wip is the jungle here), everyone who has fetched the tag would
>
> have to
>
> delete it *manually* from her copy, otherwise it will point to the
>
> wrong
>
> hash eternally.
>
>
> Another approach:
>
> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1,
>
> but
>
> *not* to the version.
>
> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
>
> maven-foo-2.16 using the SCM directly.
>
> - The version stays enduser friendly and the tag in the pom points to
>
> the
>
> sources correctly.
>
> - Diffing between different RCs and the final versions is easy.
>
> - No one has to fiddle with invalid workspaces/clones.
>
> - For the release manager it is just one additional SCM call.
>
>
> Regards Mirko
>
> --
>
> Sent from my mobile
>
> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>
>
> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>
> I do not believe that can be done with the release plugins as the
>
> pom
>
> has to specify the same version as the tag. If you then rename the
>
> tag you
>
> would have to modify the poms in the tag, which makes the release
>
> invalid.
>
>
> Have you ever used the release plugin? If not, I would suggest you
>
> try
>
> it and offer up patches to change it instead of carrying on this
>
> discussion
>
> as it is unlikely maven is going to stop using the release plugin.
>
>
> This is straying further off the original topic.
>
>
> Whether people use the release plugin or some other method is not
>
> really relevant to the release vote itself.
>
>
> All the process that leads up to the vote is merely a means to
>
> trying
>
> to ensure that the release candidate as as good as possible.
>
>
> What matters is the vote - the public declaration that the RC has
>
> been
>
> reviewed and approved.
>
> Only a PMC-approved vote can get the legal protection of the ASF.
>
>
> The vote needs to be performed on input that can be readily checked
>
> by
>
> any reviewer.
>
> The vote has to be seen to be open and complete.
>
> The SVN (or GIT) coordinate is an essential part of the input, as it
>
> is the only practical way to check provenance of the files in the
>
> archives.
>
>
> Given that part of the Maven philisophy is to ensure that all plugin
>
> versions must be specified to ensure repeatable builds, I'm a bit
>
> surprised how much resistance there is to providing the specific
>
> source which was used as input to the build process.
>
>
> The only change that this requires to be made to the process is to
>
> add
>
> the revision number and tag name [1] to the release vote e-mail.
>
> Is that really too much to ask?
>
>
> [1] A revision on its one is insufficient as the ASF uses a shared
>
> SVN
>
> repo; the location within the tree is needed to be able to select
>
> the
>
> revelant portion of the tree. The tag name is one such way to
>
> provide
>
> the information.
>
>
> Ralph
>
>
> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>
>
> It would be a lot better to use RC1 RC2 etc initially, and copy
>
> the
>
> successful tag to the GA tag.
>
>
> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>
> wrote:
>
> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>
> failed release vote instead of deleting them.
>
>
>
> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>
>
> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>
> ralph.goers@dslextreme.com>wrote:
>
>
> Again I have to disagree. The release manager will send an
>
> email
>
> closing
>
> the prior release. At this point all the prior release
>
> artifacts
>
> are junk
>
> even if they still exist. At some point the release manager
>
> will
>
> delete
>
> the tag and rerun the release
>
>
>
> That's a no-no IMO. Tags that have been voted on should never be
>
> deleted.
>
>
> Gary
>
>
>
>
> At this point the tag is still junk to everyone else because
>
> they
>
> have no
>
> idea what the RM is doing - so they shouldn't be making
>
> assumptions
>
> about
>
> non-released tags. Once he sends the email though the tag
>
> will be
>
> valid.
>
> Sure having the revision number helps but unless the RM
>
> completely
>
> screws
>
> up the tag should be sufficient.
>
>
> Ralph
>
>
>
> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>
>
> Not really, no. The developer may have re-spun it again and be
>
> about to
>
> email again. You have no idea what you're looking at unless
>
> you
>
> know the
>
> revision. SVN will die off within a decade and this discussion
>
> will
>
> become
>
> critical. Better to figure out how to support proper
>
> techniques
>
> now,
>
> rather
>
> than wait until forced to.
>
>
> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>
> ralph.goers@dslextreme.com
>
> wrote:
>
>
> I disagree that the revision is required. I know that the
>
> RM is
>
> going
>
> to
>
> recreate the tag with each release candidate. Therefore, so
>
> long
>
> as I
>
> refetch that tag for every release vote I can be confident
>
> that
>
> I
>
> am
>
> reviewing the release contents.
>
>
> Ralph
>
>
> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>
>
> The mission of the ASF is to release software as source,
>
> and to
>
> ensure
>
> that the released source is available under the Apache
>
> Licence.
>
>
> Before a release can be approved it must be voted on by the
>
> PMC.
>
> The review process needs to establish that the proposed
>
> source
>
> release
>
> meets those aims.
>
>
> It's all but impossible for reviewers to examine every
>
> single
>
> file in
>
> a source archive to determine if it meets the criteria.
>
> And it's not unknown for spurious files to creep into a
>
> release
>
> (perhaps from a stale workspace - are releases always built
>
> from a
>
> fresh checkout of the tag?)
>
>
> However, PMCs are also required to check what is added to
>
> the
>
> SCM
>
> (SVN/Git) to make sure it meets the required license
>
> criteria.
>
> This is done on an ongoing basis as part of reviewing
>
> check-ins
>
> and
>
> accepting new contributions.
>
> So provided that all the files in the source release are
>
> also
>
> present
>
> in SCM, the PMC can be reasonably sure that the source
>
> release
>
> meets
>
> the ASF criteria.
>
>
> Without having the SCM as a database of validated files,
>
> there
>
> are far
>
> too many files in the average source archive to check
>
> individually.
>
> And how would one check their provenance? The obvious way
>
> is to
>
> compare them with the entries in SCM.
>
>
> Therefore, I contend that a release vote does not make sense
>
> without
>
> the SCM tag.
>
> In the case of SVN, since tags are not immutable, the vote
>
> e-mail
>
> also
>
> needs the revision.
>
>
> Whether every reviewer actually checks the source archive
>
> against
>
> SCM
>
> is another matter.
>
> But if the required SCM information is not present, it
>
> would be
>
> difficult to argue that the RM had provided sufficient
>
> information for
>
> a valid review to take place.
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
>
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>
> Java Persistence with Hibernate, Second Edition<
>
> http://www.manning.com/bauer3/>
>
> JUnit in Action, Second Edition <
>
> http://www.manning.com/tahchiev/>
>
> Spring Batch in Action <http://www.manning.com/templier/>
>
> Blog: http://garygregory.wordpress.com
>
> Home: http://garygregory.com/
>
> Tweet! http://twitter.com/GaryGregory
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> --
>
> -----
>
> Arnaud Héritier
>
> http://aheritier.net
>
> Mail/GTalk: aheritier AT gmail DOT com
>
> Twitter/Skype : aheritier
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Release process updates
Posted by Gary Gregory <ga...@gmail.com>.
On Jun 28, 2013, at 7:05, Fred Cooke <fr...@gmail.com> wrote:
For git the unique hash is sufficient, you don't really need the tag at
all, they simply point to the unique hash (or another tag, in a chain). If
Git was the SCM of choice, I'd use RCX tags, and then not retag for final,
but rather point the final tag AT the last, accepted RC tag.
For example
artifact-RC1 >> 1234567890ABCDE
artifact-RC2 >> ABCDE1234567890
artifact-RC3 >> 12345ABCDE67890
artifact >> artifact-RC3 (yes this is possible! and is correctly resolved
to the hash pointed to by the final chain-link)
If I were forced (at gun point) to use SVN again, I'd not create real
SVN-tags, I'd modify my tooling to either add SVN meta data linking name
and revision number and path or do the same in a plain text file(s)
somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN
mv makes me want to cry like a girl. From the help info:
Note: this subcommand is equivalent to a 'copy' and 'delete'.
Not so anymore, see http://subversion.apache.org/docs/release-notes/1.8.html
Gary
If only file systems were this good! :-p
In terms of current SVN usage, the "SVN mv" command is probably a good
choice, as already discussed. You could argue that a "cp" would be better,
but this creates wholesale duplication, which is never good.
Fred.
On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
The re-use of tags is a side-issue to this thread, though I'm glad to
see some support for using immutable tags, whatever route is chosen
Please start a new thread to continue that discussion.
The vote e-mail must have the revision and tag name/trunk URL in it
else it is not complete.
Just as Maven insists on GAV - where V=version - a unique SVN
coordinate requires the revision and the tree segment selector (e.g.
tag).
I don't know what Git needs - I suppose it may depend on whether
multiple components are part of the same Git instance.
But whatever - as it stands, the current vote e-mail is
**incomplete**; it does not provide sufficient information for the
candidate to be properly evaluated.
The information needs to be present both for current and historical use.
On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
+1 to change our tags convention if it solves this issue by avoiding to
reuse tag names to give a better visibility from where a release was done
On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:
This suggestion is much like what we came up with the last time
we discussed this - about 3 weeks ago.
This behaviour is simple to achieve without a single line
of change; the release plugin already asks for a SCM tag name
distinct from the version number. (we *could* add some kind
of support for an explicit convention, we could even add a scm-lookup
to auto-roll forward on subsequent takes).
Now I've been trying to think if there's a sensible convention
that could be established that would allow us to
simply *keep* the tag name of the accepted version
without re-pushing another tag after release (and, since the tag
name can be etched into the pom of the released artifact, there
should be no real reason for confusion).
I've been thinking about a *tagging* convention along the lines
of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
maven-xx-plugin-2.3.2#3..."
Effectively we would delete #1 and #2 and keep the #3 tag, since this
vote passed on take 3.
maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
released 2.3.2 version.
This is mostly a policy change on tag naming, we could implement this
without a line
of code change. Since both svn and git essentially have flawed tag
handling it makes sense to do a change like this.
Kristian
2013/6/28 Ralph Goers <ra...@dslextreme.com>:
Can you provide the steps required to get the release plugin to work
this way?
Ralph
On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
Hello,
this seems to be the most popular discussion, so another 2 cents:
- Today I read the man page of git-tag again.
- It states very clearly you should never reuse tags, because unlike
is
the
case with subversion, once a git tag is out in the wild (and pushing
to
git-wip is the jungle here), everyone who has fetched the tag would
have to
delete it *manually* from her copy, otherwise it will point to the
wrong
hash eternally.
Another approach:
- Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1,
but
*not* to the version.
- *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
maven-foo-2.16 using the SCM directly.
- The version stays enduser friendly and the tag in the pom points to
the
sources correctly.
- Diffing between different RCs and the final versions is easy.
- No one has to fiddle with invalid workspaces/clones.
- For the release manager it is just one additional SCM call.
Regards Mirko
--
Sent from my mobile
On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
I do not believe that can be done with the release plugins as the
pom
has to specify the same version as the tag. If you then rename the
tag you
would have to modify the poms in the tag, which makes the release
invalid.
Have you ever used the release plugin? If not, I would suggest you
try
it and offer up patches to change it instead of carrying on this
discussion
as it is unlikely maven is going to stop using the release plugin.
This is straying further off the original topic.
Whether people use the release plugin or some other method is not
really relevant to the release vote itself.
All the process that leads up to the vote is merely a means to
trying
to ensure that the release candidate as as good as possible.
What matters is the vote - the public declaration that the RC has
been
reviewed and approved.
Only a PMC-approved vote can get the legal protection of the ASF.
The vote needs to be performed on input that can be readily checked
by
any reviewer.
The vote has to be seen to be open and complete.
The SVN (or GIT) coordinate is an essential part of the input, as it
is the only practical way to check provenance of the files in the
archives.
Given that part of the Maven philisophy is to ensure that all plugin
versions must be specified to ensure repeatable builds, I'm a bit
surprised how much resistance there is to providing the specific
source which was used as input to the build process.
The only change that this requires to be made to the process is to
add
the revision number and tag name [1] to the release vote e-mail.
Is that really too much to ask?
[1] A revision on its one is insufficient as the ASF uses a shared
SVN
repo; the location within the tree is needed to be able to select
the
revelant portion of the tree. The tag name is one such way to
provide
the information.
Ralph
On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
It would be a lot better to use RC1 RC2 etc initially, and copy
the
successful tag to the GA tag.
On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
wrote:
Yeah - I agree with this. I rename them to rc1, rc2, etc after a
failed release vote instead of deleting them.
On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
ralph.goers@dslextreme.com>wrote:
Again I have to disagree. The release manager will send an
email
closing
the prior release. At this point all the prior release
artifacts
are junk
even if they still exist. At some point the release manager
will
delete
the tag and rerun the release
That's a no-no IMO. Tags that have been voted on should never be
deleted.
Gary
At this point the tag is still junk to everyone else because
they
have no
idea what the RM is doing - so they shouldn't be making
assumptions
about
non-released tags. Once he sends the email though the tag
will be
valid.
Sure having the revision number helps but unless the RM
completely
screws
up the tag should be sufficient.
Ralph
On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
Not really, no. The developer may have re-spun it again and be
about to
email again. You have no idea what you're looking at unless
you
know the
revision. SVN will die off within a decade and this discussion
will
become
critical. Better to figure out how to support proper
techniques
now,
rather
than wait until forced to.
On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
ralph.goers@dslextreme.com
wrote:
I disagree that the revision is required. I know that the
RM is
going
to
recreate the tag with each release candidate. Therefore, so
long
as I
refetch that tag for every release vote I can be confident
that
I
am
reviewing the release contents.
Ralph
On Jun 25, 2013, at 9:52 AM, sebb wrote:
The mission of the ASF is to release software as source,
and to
ensure
that the released source is available under the Apache
Licence.
Before a release can be approved it must be voted on by the
PMC.
The review process needs to establish that the proposed
source
release
meets those aims.
It's all but impossible for reviewers to examine every
single
file in
a source archive to determine if it meets the criteria.
And it's not unknown for spurious files to creep into a
release
(perhaps from a stale workspace - are releases always built
from a
fresh checkout of the tag?)
However, PMCs are also required to check what is added to
the
SCM
(SVN/Git) to make sure it meets the required license
criteria.
This is done on an ongoing basis as part of reviewing
check-ins
and
accepting new contributions.
So provided that all the files in the source release are
also
present
in SCM, the PMC can be reasonably sure that the source
release
meets
the ASF criteria.
Without having the SCM as a database of validated files,
there
are far
too many files in the average source archive to check
individually.
And how would one check their provenance? The obvious way
is to
compare them with the entries in SCM.
Therefore, I contend that a release vote does not make sense
without
the SCM tag.
In the case of SVN, since tags are not immutable, the vote
e-mail
also
needs the revision.
Whether every reviewer actually checks the source archive
against
SCM
is another matter.
But if the required SCM information is not present, it
would be
difficult to argue that the RM had provided sufficient
information for
a valid review to take place.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<
http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <
http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Fred Cooke <fr...@gmail.com>.
For git the unique hash is sufficient, you don't really need the tag at
all, they simply point to the unique hash (or another tag, in a chain). If
Git was the SCM of choice, I'd use RCX tags, and then not retag for final,
but rather point the final tag AT the last, accepted RC tag.
For example
artifact-RC1 >> 1234567890ABCDE
artifact-RC2 >> ABCDE1234567890
artifact-RC3 >> 12345ABCDE67890
artifact >> artifact-RC3 (yes this is possible! and is correctly resolved
to the hash pointed to by the final chain-link)
If I were forced (at gun point) to use SVN again, I'd not create real
SVN-tags, I'd modify my tooling to either add SVN meta data linking name
and revision number and path or do the same in a plain text file(s)
somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN
mv makes me want to cry like a girl. From the help info:
Note: this subcommand is equivalent to a 'copy' and 'delete'.
>
If only file systems were this good! :-p
In terms of current SVN usage, the "SVN mv" command is probably a good
choice, as already discussed. You could argue that a "cp" would be better,
but this creates wholesale duplication, which is never good.
Fred.
On Fri, Jun 28, 2013 at 12:35 PM, sebb <se...@gmail.com> wrote:
> The re-use of tags is a side-issue to this thread, though I'm glad to
> see some support for using immutable tags, whatever route is chosen
> Please start a new thread to continue that discussion.
>
> The vote e-mail must have the revision and tag name/trunk URL in it
> else it is not complete.
>
> Just as Maven insists on GAV - where V=version - a unique SVN
> coordinate requires the revision and the tree segment selector (e.g.
> tag).
> I don't know what Git needs - I suppose it may depend on whether
> multiple components are part of the same Git instance.
>
> But whatever - as it stands, the current vote e-mail is
> **incomplete**; it does not provide sufficient information for the
> candidate to be properly evaluated.
> The information needs to be present both for current and historical use.
>
> On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
> > +1 to change our tags convention if it solves this issue by avoiding to
> > reuse tag names to give a better visibility from where a release was done
> >
> >
> > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
> > kristian.rosenvold@gmail.com> wrote:
> >
> >> This suggestion is much like what we came up with the last time
> >> we discussed this - about 3 weeks ago.
> >>
> >> This behaviour is simple to achieve without a single line
> >> of change; the release plugin already asks for a SCM tag name
> >> distinct from the version number. (we *could* add some kind
> >> of support for an explicit convention, we could even add a scm-lookup
> >> to auto-roll forward on subsequent takes).
> >>
> >> Now I've been trying to think if there's a sensible convention
> >> that could be established that would allow us to
> >> simply *keep* the tag name of the accepted version
> >> without re-pushing another tag after release (and, since the tag
> >> name can be etched into the pom of the released artifact, there
> >> should be no real reason for confusion).
> >>
> >> I've been thinking about a *tagging* convention along the lines
> >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> >> maven-xx-plugin-2.3.2#3..."
> >>
> >> Effectively we would delete #1 and #2 and keep the #3 tag, since this
> >> vote passed on take 3.
> >>
> >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
> >> released 2.3.2 version.
> >>
> >> This is mostly a policy change on tag naming, we could implement this
> >> without a line
> >> of code change. Since both svn and git essentially have flawed tag
> >> handling it makes sense to do a change like this.
> >>
> >> Kristian
> >>
> >> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> >> > Can you provide the steps required to get the release plugin to work
> >> this way?
> >> >
> >> > Ralph
> >> >
> >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> this seems to be the most popular discussion, so another 2 cents:
> >> >> - Today I read the man page of git-tag again.
> >> >> - It states very clearly you should never reuse tags, because unlike
> is
> >> the
> >> >> case with subversion, once a git tag is out in the wild (and pushing
> to
> >> >> git-wip is the jungle here), everyone who has fetched the tag would
> >> have to
> >> >> delete it *manually* from her copy, otherwise it will point to the
> wrong
> >> >> hash eternally.
> >> >>
> >> >> Another approach:
> >> >> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1,
> >> but
> >> >> *not* to the version.
> >> >> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
> >> >> maven-foo-2.16 using the SCM directly.
> >> >> - The version stays enduser friendly and the tag in the pom points to
> >> the
> >> >> sources correctly.
> >> >> - Diffing between different RCs and the final versions is easy.
> >> >> - No one has to fiddle with invalid workspaces/clones.
> >> >> - For the release manager it is just one additional SCM call.
> >> >>
> >> >> Regards Mirko
> >> >> --
> >> >> Sent from my mobile
> >> >> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
> >> >>
> >> >>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
> >> >>>> I do not believe that can be done with the release plugins as the
> pom
> >> >>> has to specify the same version as the tag. If you then rename the
> >> tag you
> >> >>> would have to modify the poms in the tag, which makes the release
> >> invalid.
> >> >>>>
> >> >>>> Have you ever used the release plugin? If not, I would suggest you
> >> try
> >> >>> it and offer up patches to change it instead of carrying on this
> >> discussion
> >> >>> as it is unlikely maven is going to stop using the release plugin.
> >> >>>
> >> >>> This is straying further off the original topic.
> >> >>>
> >> >>> Whether people use the release plugin or some other method is not
> >> >>> really relevant to the release vote itself.
> >> >>>
> >> >>> All the process that leads up to the vote is merely a means to
> trying
> >> >>> to ensure that the release candidate as as good as possible.
> >> >>>
> >> >>> What matters is the vote - the public declaration that the RC has
> been
> >> >>> reviewed and approved.
> >> >>> Only a PMC-approved vote can get the legal protection of the ASF.
> >> >>>
> >> >>> The vote needs to be performed on input that can be readily checked
> by
> >> >>> any reviewer.
> >> >>> The vote has to be seen to be open and complete.
> >> >>> The SVN (or GIT) coordinate is an essential part of the input, as it
> >> >>> is the only practical way to check provenance of the files in the
> >> >>> archives.
> >> >>>
> >> >>> Given that part of the Maven philisophy is to ensure that all plugin
> >> >>> versions must be specified to ensure repeatable builds, I'm a bit
> >> >>> surprised how much resistance there is to providing the specific
> >> >>> source which was used as input to the build process.
> >> >>>
> >> >>> The only change that this requires to be made to the process is to
> add
> >> >>> the revision number and tag name [1] to the release vote e-mail.
> >> >>> Is that really too much to ask?
> >> >>>
> >> >>> [1] A revision on its one is insufficient as the ASF uses a shared
> SVN
> >> >>> repo; the location within the tree is needed to be able to select
> the
> >> >>> revelant portion of the tree. The tag name is one such way to
> provide
> >> >>> the information.
> >> >>>
> >> >>>> Ralph
> >> >>>>
> >> >>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
> >> >>>>
> >> >>>>> It would be a lot better to use RC1 RC2 etc initially, and copy
> the
> >> >>>>> successful tag to the GA tag.
> >> >>>>>
> >> >>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
> >> wrote:
> >> >>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
> >> >>> failed release vote instead of deleting them.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >> >>>>>>
> >> >>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> >> >>> ralph.goers@dslextreme.com>wrote:
> >> >>>>>>>
> >> >>>>>>>> Again I have to disagree. The release manager will send an
> email
> >> >>> closing
> >> >>>>>>>> the prior release. At this point all the prior release
> artifacts
> >> >>> are junk
> >> >>>>>>>> even if they still exist. At some point the release manager
> will
> >> >>> delete
> >> >>>>>>>> the tag and rerun the release
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> That's a no-no IMO. Tags that have been voted on should never be
> >> >>> deleted.
> >> >>>>>>>
> >> >>>>>>> Gary
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> At this point the tag is still junk to everyone else because
> they
> >> >>> have no
> >> >>>>>>>> idea what the RM is doing - so they shouldn't be making
> >> assumptions
> >> >>> about
> >> >>>>>>>> non-released tags. Once he sends the email though the tag
> will be
> >> >>> valid.
> >> >>>>>>>> Sure having the revision number helps but unless the RM
> completely
> >> >>> screws
> >> >>>>>>>> up the tag should be sufficient.
> >> >>>>>>>>
> >> >>>>>>>> Ralph
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >> >>>>>>>>
> >> >>>>>>>>> Not really, no. The developer may have re-spun it again and be
> >> >>> about to
> >> >>>>>>>>> email again. You have no idea what you're looking at unless
> you
> >> >>> know the
> >> >>>>>>>>> revision. SVN will die off within a decade and this discussion
> >> will
> >> >>>>>>>> become
> >> >>>>>>>>> critical. Better to figure out how to support proper
> techniques
> >> now,
> >> >>>>>>>> rather
> >> >>>>>>>>> than wait until forced to.
> >> >>>>>>>>>
> >> >>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> >> >>> ralph.goers@dslextreme.com
> >> >>>>>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>> I disagree that the revision is required. I know that the
> RM is
> >> >>> going
> >> >>>>>>>> to
> >> >>>>>>>>>> recreate the tag with each release candidate. Therefore, so
> >> long
> >> >>> as I
> >> >>>>>>>>>> refetch that tag for every release vote I can be confident
> that
> >> I
> >> >>> am
> >> >>>>>>>>>> reviewing the release contents.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Ralph
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> The mission of the ASF is to release software as source,
> and to
> >> >>> ensure
> >> >>>>>>>>>>> that the released source is available under the Apache
> Licence.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Before a release can be approved it must be voted on by the
> >> PMC.
> >> >>>>>>>>>>> The review process needs to establish that the proposed
> source
> >> >>> release
> >> >>>>>>>>>>> meets those aims.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> It's all but impossible for reviewers to examine every
> single
> >> >>> file in
> >> >>>>>>>>>>> a source archive to determine if it meets the criteria.
> >> >>>>>>>>>>> And it's not unknown for spurious files to creep into a
> release
> >> >>>>>>>>>>> (perhaps from a stale workspace - are releases always built
> >> from a
> >> >>>>>>>>>>> fresh checkout of the tag?)
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> However, PMCs are also required to check what is added to
> the
> >> SCM
> >> >>>>>>>>>>> (SVN/Git) to make sure it meets the required license
> criteria.
> >> >>>>>>>>>>> This is done on an ongoing basis as part of reviewing
> check-ins
> >> >>> and
> >> >>>>>>>>>>> accepting new contributions.
> >> >>>>>>>>>>> So provided that all the files in the source release are
> also
> >> >>> present
> >> >>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source
> release
> >> >>> meets
> >> >>>>>>>>>>> the ASF criteria.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Without having the SCM as a database of validated files,
> there
> >> >>> are far
> >> >>>>>>>>>>> too many files in the average source archive to check
> >> >>> individually.
> >> >>>>>>>>>>> And how would one check their provenance? The obvious way
> is to
> >> >>>>>>>>>>> compare them with the entries in SCM.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Therefore, I contend that a release vote does not make sense
> >> >>> without
> >> >>>>>>>>>>> the SCM tag.
> >> >>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote
> >> e-mail
> >> >>> also
> >> >>>>>>>>>>> needs the revision.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Whether every reviewer actually checks the source archive
> >> against
> >> >>> SCM
> >> >>>>>>>>>>> is another matter.
> >> >>>>>>>>>>> But if the required SCM information is not present, it
> would be
> >> >>>>>>>>>>> difficult to argue that the RM had provided sufficient
> >> >>> information for
> >> >>>>>>>>>>> a valid review to take place.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>>>>>> Java Persistence with Hibernate, Second Edition<
> >> >>> http://www.manning.com/bauer3/>
> >> >>>>>>> JUnit in Action, Second Edition <
> http://www.manning.com/tahchiev/>
> >> >>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >> >>>>>>> Blog: http://garygregory.wordpress.com
> >> >>>>>>> Home: http://garygregory.com/
> >> >>>>>>> Tweet! http://twitter.com/GaryGregory
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> >>>>>
> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> >>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>
> >> >>>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by Chris Graham <ch...@gmail.com>.
On Fri, Jun 28, 2013 at 8:35 PM, sebb <se...@gmail.com> wrote:
> The re-use of tags is a side-issue to this thread, though I'm glad to
> see some support for using immutable tags, whatever route is chosen
> Please start a new thread to continue that discussion.
>
>
We had that discussion, as already noted here, about three weeks ago, which
is why I asked you to drop it, as it had already been well debated.
> The vote e-mail must have the revision and tag name/trunk URL in it
> else it is not complete.
>
> Just as Maven insists on GAV - where V=version - a unique SVN
> coordinate requires the revision and the tree segment selector (e.g.
> tag).
>
I do wish you had done what I and others have invited you to do, namely use
the release plugin. If you had, you'd have seen that the release plugin
uses a svn copy to create the tag. A tag, in this instance is a lebel, or
sym link for a revision.
In this context, your statement "- a unique SVN coordinate requires the
revision and the tree segment selector (e.g. tag)." makes no sense. As, by
definition, a SVN revision is unique. That was one of the great advantages
of SVN over CVS, atomic commits (ie no partial commits).
A tag *IS* a revision and is thus unique.
> I don't know what Git needs - I suppose it may depend on whether
> multiple components are part of the same Git instance.
>
> But whatever - as it stands, the current vote e-mail is
> **incomplete**; it does not provide sufficient information for the
> candidate to be properly evaluated.
> The information needs to be present both for current and historical use.
>
> On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
> > +1 to change our tags convention if it solves this issue by avoiding to
> > reuse tag names to give a better visibility from where a release was done
> >
> >
> > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
> > kristian.rosenvold@gmail.com> wrote:
> >
> >> This suggestion is much like what we came up with the last time
> >> we discussed this - about 3 weeks ago.
> >>
> >> This behaviour is simple to achieve without a single line
> >> of change; the release plugin already asks for a SCM tag name
> >> distinct from the version number. (we *could* add some kind
> >> of support for an explicit convention, we could even add a scm-lookup
> >> to auto-roll forward on subsequent takes).
> >>
> >> Now I've been trying to think if there's a sensible convention
> >> that could be established that would allow us to
> >> simply *keep* the tag name of the accepted version
> >> without re-pushing another tag after release (and, since the tag
> >> name can be etched into the pom of the released artifact, there
> >> should be no real reason for confusion).
> >>
> >> I've been thinking about a *tagging* convention along the lines
> >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> >> maven-xx-plugin-2.3.2#3..."
> >>
> >> Effectively we would delete #1 and #2 and keep the #3 tag, since this
> >> vote passed on take 3.
> >>
> >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
> >> released 2.3.2 version.
> >>
> >> This is mostly a policy change on tag naming, we could implement this
> >> without a line
> >> of code change. Since both svn and git essentially have flawed tag
> >> handling it makes sense to do a change like this.
> >>
> >> Kristian
> >>
> >> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> >> > Can you provide the steps required to get the release plugin to work
> >> this way?
> >> >
> >> > Ralph
> >> >
> >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> this seems to be the most popular discussion, so another 2 cents:
> >> >> - Today I read the man page of git-tag again.
> >> >> - It states very clearly you should never reuse tags, because unlike
> is
> >> the
> >> >> case with subversion, once a git tag is out in the wild (and pushing
> to
> >> >> git-wip is the jungle here), everyone who has fetched the tag would
> >> have to
> >> >> delete it *manually* from her copy, otherwise it will point to the
> wrong
> >> >> hash eternally.
> >> >>
> >> >> Another approach:
> >> >> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1,
> >> but
> >> >> *not* to the version.
> >> >> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
> >> >> maven-foo-2.16 using the SCM directly.
> >> >> - The version stays enduser friendly and the tag in the pom points to
> >> the
> >> >> sources correctly.
> >> >> - Diffing between different RCs and the final versions is easy.
> >> >> - No one has to fiddle with invalid workspaces/clones.
> >> >> - For the release manager it is just one additional SCM call.
> >> >>
> >> >> Regards Mirko
> >> >> --
> >> >> Sent from my mobile
> >> >> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
> >> >>
> >> >>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
> >> >>>> I do not believe that can be done with the release plugins as the
> pom
> >> >>> has to specify the same version as the tag. If you then rename the
> >> tag you
> >> >>> would have to modify the poms in the tag, which makes the release
> >> invalid.
> >> >>>>
> >> >>>> Have you ever used the release plugin? If not, I would suggest you
> >> try
> >> >>> it and offer up patches to change it instead of carrying on this
> >> discussion
> >> >>> as it is unlikely maven is going to stop using the release plugin.
> >> >>>
> >> >>> This is straying further off the original topic.
> >> >>>
> >> >>> Whether people use the release plugin or some other method is not
> >> >>> really relevant to the release vote itself.
> >> >>>
> >> >>> All the process that leads up to the vote is merely a means to
> trying
> >> >>> to ensure that the release candidate as as good as possible.
> >> >>>
> >> >>> What matters is the vote - the public declaration that the RC has
> been
> >> >>> reviewed and approved.
> >> >>> Only a PMC-approved vote can get the legal protection of the ASF.
> >> >>>
> >> >>> The vote needs to be performed on input that can be readily checked
> by
> >> >>> any reviewer.
> >> >>> The vote has to be seen to be open and complete.
> >> >>> The SVN (or GIT) coordinate is an essential part of the input, as it
> >> >>> is the only practical way to check provenance of the files in the
> >> >>> archives.
> >> >>>
> >> >>> Given that part of the Maven philisophy is to ensure that all plugin
> >> >>> versions must be specified to ensure repeatable builds, I'm a bit
> >> >>> surprised how much resistance there is to providing the specific
> >> >>> source which was used as input to the build process.
> >> >>>
> >> >>> The only change that this requires to be made to the process is to
> add
> >> >>> the revision number and tag name [1] to the release vote e-mail.
> >> >>> Is that really too much to ask?
> >> >>>
> >> >>> [1] A revision on its one is insufficient as the ASF uses a shared
> SVN
> >> >>> repo; the location within the tree is needed to be able to select
> the
> >> >>> revelant portion of the tree. The tag name is one such way to
> provide
> >> >>> the information.
> >> >>>
> >> >>>> Ralph
> >> >>>>
> >> >>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
> >> >>>>
> >> >>>>> It would be a lot better to use RC1 RC2 etc initially, and copy
> the
> >> >>>>> successful tag to the GA tag.
> >> >>>>>
> >> >>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
> >> wrote:
> >> >>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
> >> >>> failed release vote instead of deleting them.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >> >>>>>>
> >> >>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> >> >>> ralph.goers@dslextreme.com>wrote:
> >> >>>>>>>
> >> >>>>>>>> Again I have to disagree. The release manager will send an
> email
> >> >>> closing
> >> >>>>>>>> the prior release. At this point all the prior release
> artifacts
> >> >>> are junk
> >> >>>>>>>> even if they still exist. At some point the release manager
> will
> >> >>> delete
> >> >>>>>>>> the tag and rerun the release
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> That's a no-no IMO. Tags that have been voted on should never be
> >> >>> deleted.
> >> >>>>>>>
> >> >>>>>>> Gary
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>> At this point the tag is still junk to everyone else because
> they
> >> >>> have no
> >> >>>>>>>> idea what the RM is doing - so they shouldn't be making
> >> assumptions
> >> >>> about
> >> >>>>>>>> non-released tags. Once he sends the email though the tag
> will be
> >> >>> valid.
> >> >>>>>>>> Sure having the revision number helps but unless the RM
> completely
> >> >>> screws
> >> >>>>>>>> up the tag should be sufficient.
> >> >>>>>>>>
> >> >>>>>>>> Ralph
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >> >>>>>>>>
> >> >>>>>>>>> Not really, no. The developer may have re-spun it again and be
> >> >>> about to
> >> >>>>>>>>> email again. You have no idea what you're looking at unless
> you
> >> >>> know the
> >> >>>>>>>>> revision. SVN will die off within a decade and this discussion
> >> will
> >> >>>>>>>> become
> >> >>>>>>>>> critical. Better to figure out how to support proper
> techniques
> >> now,
> >> >>>>>>>> rather
> >> >>>>>>>>> than wait until forced to.
> >> >>>>>>>>>
> >> >>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> >> >>> ralph.goers@dslextreme.com
> >> >>>>>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>> I disagree that the revision is required. I know that the
> RM is
> >> >>> going
> >> >>>>>>>> to
> >> >>>>>>>>>> recreate the tag with each release candidate. Therefore, so
> >> long
> >> >>> as I
> >> >>>>>>>>>> refetch that tag for every release vote I can be confident
> that
> >> I
> >> >>> am
> >> >>>>>>>>>> reviewing the release contents.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Ralph
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> The mission of the ASF is to release software as source,
> and to
> >> >>> ensure
> >> >>>>>>>>>>> that the released source is available under the Apache
> Licence.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Before a release can be approved it must be voted on by the
> >> PMC.
> >> >>>>>>>>>>> The review process needs to establish that the proposed
> source
> >> >>> release
> >> >>>>>>>>>>> meets those aims.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> It's all but impossible for reviewers to examine every
> single
> >> >>> file in
> >> >>>>>>>>>>> a source archive to determine if it meets the criteria.
> >> >>>>>>>>>>> And it's not unknown for spurious files to creep into a
> release
> >> >>>>>>>>>>> (perhaps from a stale workspace - are releases always built
> >> from a
> >> >>>>>>>>>>> fresh checkout of the tag?)
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> However, PMCs are also required to check what is added to
> the
> >> SCM
> >> >>>>>>>>>>> (SVN/Git) to make sure it meets the required license
> criteria.
> >> >>>>>>>>>>> This is done on an ongoing basis as part of reviewing
> check-ins
> >> >>> and
> >> >>>>>>>>>>> accepting new contributions.
> >> >>>>>>>>>>> So provided that all the files in the source release are
> also
> >> >>> present
> >> >>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source
> release
> >> >>> meets
> >> >>>>>>>>>>> the ASF criteria.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Without having the SCM as a database of validated files,
> there
> >> >>> are far
> >> >>>>>>>>>>> too many files in the average source archive to check
> >> >>> individually.
> >> >>>>>>>>>>> And how would one check their provenance? The obvious way
> is to
> >> >>>>>>>>>>> compare them with the entries in SCM.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Therefore, I contend that a release vote does not make sense
> >> >>> without
> >> >>>>>>>>>>> the SCM tag.
> >> >>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote
> >> e-mail
> >> >>> also
> >> >>>>>>>>>>> needs the revision.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Whether every reviewer actually checks the source archive
> >> against
> >> >>> SCM
> >> >>>>>>>>>>> is another matter.
> >> >>>>>>>>>>> But if the required SCM information is not present, it
> would be
> >> >>>>>>>>>>> difficult to argue that the RM had provided sufficient
> >> >>> information for
> >> >>>>>>>>>>> a valid review to take place.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>>>>>> Java Persistence with Hibernate, Second Edition<
> >> >>> http://www.manning.com/bauer3/>
> >> >>>>>>> JUnit in Action, Second Edition <
> http://www.manning.com/tahchiev/>
> >> >>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >> >>>>>>> Blog: http://garygregory.wordpress.com
> >> >>>>>>> Home: http://garygregory.com/
> >> >>>>>>> Tweet! http://twitter.com/GaryGregory
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> >>>>>
> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> >>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>
> >> >>>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by sebb <se...@gmail.com>.
The re-use of tags is a side-issue to this thread, though I'm glad to
see some support for using immutable tags, whatever route is chosen
Please start a new thread to continue that discussion.
The vote e-mail must have the revision and tag name/trunk URL in it
else it is not complete.
Just as Maven insists on GAV - where V=version - a unique SVN
coordinate requires the revision and the tree segment selector (e.g.
tag).
I don't know what Git needs - I suppose it may depend on whether
multiple components are part of the same Git instance.
But whatever - as it stands, the current vote e-mail is
**incomplete**; it does not provide sufficient information for the
candidate to be properly evaluated.
The information needs to be present both for current and historical use.
On 28 June 2013 10:09, Arnaud Héritier <ah...@gmail.com> wrote:
> +1 to change our tags convention if it solves this issue by avoiding to
> reuse tag names to give a better visibility from where a release was done
>
>
> On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
>> This suggestion is much like what we came up with the last time
>> we discussed this - about 3 weeks ago.
>>
>> This behaviour is simple to achieve without a single line
>> of change; the release plugin already asks for a SCM tag name
>> distinct from the version number. (we *could* add some kind
>> of support for an explicit convention, we could even add a scm-lookup
>> to auto-roll forward on subsequent takes).
>>
>> Now I've been trying to think if there's a sensible convention
>> that could be established that would allow us to
>> simply *keep* the tag name of the accepted version
>> without re-pushing another tag after release (and, since the tag
>> name can be etched into the pom of the released artifact, there
>> should be no real reason for confusion).
>>
>> I've been thinking about a *tagging* convention along the lines
>> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
>> maven-xx-plugin-2.3.2#3..."
>>
>> Effectively we would delete #1 and #2 and keep the #3 tag, since this
>> vote passed on take 3.
>>
>> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
>> released 2.3.2 version.
>>
>> This is mostly a policy change on tag naming, we could implement this
>> without a line
>> of code change. Since both svn and git essentially have flawed tag
>> handling it makes sense to do a change like this.
>>
>> Kristian
>>
>> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>> > Can you provide the steps required to get the release plugin to work
>> this way?
>> >
>> > Ralph
>> >
>> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>> >
>> >> Hello,
>> >>
>> >> this seems to be the most popular discussion, so another 2 cents:
>> >> - Today I read the man page of git-tag again.
>> >> - It states very clearly you should never reuse tags, because unlike is
>> the
>> >> case with subversion, once a git tag is out in the wild (and pushing to
>> >> git-wip is the jungle here), everyone who has fetched the tag would
>> have to
>> >> delete it *manually* from her copy, otherwise it will point to the wrong
>> >> hash eternally.
>> >>
>> >> Another approach:
>> >> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1,
>> but
>> >> *not* to the version.
>> >> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
>> >> maven-foo-2.16 using the SCM directly.
>> >> - The version stays enduser friendly and the tag in the pom points to
>> the
>> >> sources correctly.
>> >> - Diffing between different RCs and the final versions is easy.
>> >> - No one has to fiddle with invalid workspaces/clones.
>> >> - For the release manager it is just one additional SCM call.
>> >>
>> >> Regards Mirko
>> >> --
>> >> Sent from my mobile
>> >> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>> >>
>> >>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>> >>>> I do not believe that can be done with the release plugins as the pom
>> >>> has to specify the same version as the tag. If you then rename the
>> tag you
>> >>> would have to modify the poms in the tag, which makes the release
>> invalid.
>> >>>>
>> >>>> Have you ever used the release plugin? If not, I would suggest you
>> try
>> >>> it and offer up patches to change it instead of carrying on this
>> discussion
>> >>> as it is unlikely maven is going to stop using the release plugin.
>> >>>
>> >>> This is straying further off the original topic.
>> >>>
>> >>> Whether people use the release plugin or some other method is not
>> >>> really relevant to the release vote itself.
>> >>>
>> >>> All the process that leads up to the vote is merely a means to trying
>> >>> to ensure that the release candidate as as good as possible.
>> >>>
>> >>> What matters is the vote - the public declaration that the RC has been
>> >>> reviewed and approved.
>> >>> Only a PMC-approved vote can get the legal protection of the ASF.
>> >>>
>> >>> The vote needs to be performed on input that can be readily checked by
>> >>> any reviewer.
>> >>> The vote has to be seen to be open and complete.
>> >>> The SVN (or GIT) coordinate is an essential part of the input, as it
>> >>> is the only practical way to check provenance of the files in the
>> >>> archives.
>> >>>
>> >>> Given that part of the Maven philisophy is to ensure that all plugin
>> >>> versions must be specified to ensure repeatable builds, I'm a bit
>> >>> surprised how much resistance there is to providing the specific
>> >>> source which was used as input to the build process.
>> >>>
>> >>> The only change that this requires to be made to the process is to add
>> >>> the revision number and tag name [1] to the release vote e-mail.
>> >>> Is that really too much to ask?
>> >>>
>> >>> [1] A revision on its one is insufficient as the ASF uses a shared SVN
>> >>> repo; the location within the tree is needed to be able to select the
>> >>> revelant portion of the tree. The tag name is one such way to provide
>> >>> the information.
>> >>>
>> >>>> Ralph
>> >>>>
>> >>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>> >>>>
>> >>>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>> >>>>> successful tag to the GA tag.
>> >>>>>
>> >>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>> >>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>> >>> failed release vote instead of deleting them.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>> >>>>>>
>> >>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>> >>> ralph.goers@dslextreme.com>wrote:
>> >>>>>>>
>> >>>>>>>> Again I have to disagree. The release manager will send an email
>> >>> closing
>> >>>>>>>> the prior release. At this point all the prior release artifacts
>> >>> are junk
>> >>>>>>>> even if they still exist. At some point the release manager will
>> >>> delete
>> >>>>>>>> the tag and rerun the release
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> That's a no-no IMO. Tags that have been voted on should never be
>> >>> deleted.
>> >>>>>>>
>> >>>>>>> Gary
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> At this point the tag is still junk to everyone else because they
>> >>> have no
>> >>>>>>>> idea what the RM is doing - so they shouldn't be making
>> assumptions
>> >>> about
>> >>>>>>>> non-released tags. Once he sends the email though the tag will be
>> >>> valid.
>> >>>>>>>> Sure having the revision number helps but unless the RM completely
>> >>> screws
>> >>>>>>>> up the tag should be sufficient.
>> >>>>>>>>
>> >>>>>>>> Ralph
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>> >>>>>>>>
>> >>>>>>>>> Not really, no. The developer may have re-spun it again and be
>> >>> about to
>> >>>>>>>>> email again. You have no idea what you're looking at unless you
>> >>> know the
>> >>>>>>>>> revision. SVN will die off within a decade and this discussion
>> will
>> >>>>>>>> become
>> >>>>>>>>> critical. Better to figure out how to support proper techniques
>> now,
>> >>>>>>>> rather
>> >>>>>>>>> than wait until forced to.
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>> >>> ralph.goers@dslextreme.com
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> I disagree that the revision is required. I know that the RM is
>> >>> going
>> >>>>>>>> to
>> >>>>>>>>>> recreate the tag with each release candidate. Therefore, so
>> long
>> >>> as I
>> >>>>>>>>>> refetch that tag for every release vote I can be confident that
>> I
>> >>> am
>> >>>>>>>>>> reviewing the release contents.
>> >>>>>>>>>>
>> >>>>>>>>>> Ralph
>> >>>>>>>>>>
>> >>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> The mission of the ASF is to release software as source, and to
>> >>> ensure
>> >>>>>>>>>>> that the released source is available under the Apache Licence.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Before a release can be approved it must be voted on by the
>> PMC.
>> >>>>>>>>>>> The review process needs to establish that the proposed source
>> >>> release
>> >>>>>>>>>>> meets those aims.
>> >>>>>>>>>>>
>> >>>>>>>>>>> It's all but impossible for reviewers to examine every single
>> >>> file in
>> >>>>>>>>>>> a source archive to determine if it meets the criteria.
>> >>>>>>>>>>> And it's not unknown for spurious files to creep into a release
>> >>>>>>>>>>> (perhaps from a stale workspace - are releases always built
>> from a
>> >>>>>>>>>>> fresh checkout of the tag?)
>> >>>>>>>>>>>
>> >>>>>>>>>>> However, PMCs are also required to check what is added to the
>> SCM
>> >>>>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>> >>>>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
>> >>> and
>> >>>>>>>>>>> accepting new contributions.
>> >>>>>>>>>>> So provided that all the files in the source release are also
>> >>> present
>> >>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source release
>> >>> meets
>> >>>>>>>>>>> the ASF criteria.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Without having the SCM as a database of validated files, there
>> >>> are far
>> >>>>>>>>>>> too many files in the average source archive to check
>> >>> individually.
>> >>>>>>>>>>> And how would one check their provenance? The obvious way is to
>> >>>>>>>>>>> compare them with the entries in SCM.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Therefore, I contend that a release vote does not make sense
>> >>> without
>> >>>>>>>>>>> the SCM tag.
>> >>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote
>> e-mail
>> >>> also
>> >>>>>>>>>>> needs the revision.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Whether every reviewer actually checks the source archive
>> against
>> >>> SCM
>> >>>>>>>>>>> is another matter.
>> >>>>>>>>>>> But if the required SCM information is not present, it would be
>> >>>>>>>>>>> difficult to argue that the RM had provided sufficient
>> >>> information for
>> >>>>>>>>>>> a valid review to take place.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>> ---------------------------------------------------------------------
>> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>> ---------------------------------------------------------------------
>> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>>>>>> Java Persistence with Hibernate, Second Edition<
>> >>> http://www.manning.com/bauer3/>
>> >>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>> >>>>>>> Blog: http://garygregory.wordpress.com
>> >>>>>>> Home: http://garygregory.com/
>> >>>>>>> Tweet! http://twitter.com/GaryGregory
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>
>> >>>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Arnaud Héritier <ah...@gmail.com>.
+1 to change our tags convention if it solves this issue by avoiding to
reuse tag names to give a better visibility from where a release was done
On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:
> This suggestion is much like what we came up with the last time
> we discussed this - about 3 weeks ago.
>
> This behaviour is simple to achieve without a single line
> of change; the release plugin already asks for a SCM tag name
> distinct from the version number. (we *could* add some kind
> of support for an explicit convention, we could even add a scm-lookup
> to auto-roll forward on subsequent takes).
>
> Now I've been trying to think if there's a sensible convention
> that could be established that would allow us to
> simply *keep* the tag name of the accepted version
> without re-pushing another tag after release (and, since the tag
> name can be etched into the pom of the released artifact, there
> should be no real reason for confusion).
>
> I've been thinking about a *tagging* convention along the lines
> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> maven-xx-plugin-2.3.2#3..."
>
> Effectively we would delete #1 and #2 and keep the #3 tag, since this
> vote passed on take 3.
>
> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
> released 2.3.2 version.
>
> This is mostly a policy change on tag naming, we could implement this
> without a line
> of code change. Since both svn and git essentially have flawed tag
> handling it makes sense to do a change like this.
>
> Kristian
>
> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> > Can you provide the steps required to get the release plugin to work
> this way?
> >
> > Ralph
> >
> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> >
> >> Hello,
> >>
> >> this seems to be the most popular discussion, so another 2 cents:
> >> - Today I read the man page of git-tag again.
> >> - It states very clearly you should never reuse tags, because unlike is
> the
> >> case with subversion, once a git tag is out in the wild (and pushing to
> >> git-wip is the jungle here), everyone who has fetched the tag would
> have to
> >> delete it *manually* from her copy, otherwise it will point to the wrong
> >> hash eternally.
> >>
> >> Another approach:
> >> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1,
> but
> >> *not* to the version.
> >> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
> >> maven-foo-2.16 using the SCM directly.
> >> - The version stays enduser friendly and the tag in the pom points to
> the
> >> sources correctly.
> >> - Diffing between different RCs and the final versions is easy.
> >> - No one has to fiddle with invalid workspaces/clones.
> >> - For the release manager it is just one additional SCM call.
> >>
> >> Regards Mirko
> >> --
> >> Sent from my mobile
> >> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
> >>
> >>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
> >>>> I do not believe that can be done with the release plugins as the pom
> >>> has to specify the same version as the tag. If you then rename the
> tag you
> >>> would have to modify the poms in the tag, which makes the release
> invalid.
> >>>>
> >>>> Have you ever used the release plugin? If not, I would suggest you
> try
> >>> it and offer up patches to change it instead of carrying on this
> discussion
> >>> as it is unlikely maven is going to stop using the release plugin.
> >>>
> >>> This is straying further off the original topic.
> >>>
> >>> Whether people use the release plugin or some other method is not
> >>> really relevant to the release vote itself.
> >>>
> >>> All the process that leads up to the vote is merely a means to trying
> >>> to ensure that the release candidate as as good as possible.
> >>>
> >>> What matters is the vote - the public declaration that the RC has been
> >>> reviewed and approved.
> >>> Only a PMC-approved vote can get the legal protection of the ASF.
> >>>
> >>> The vote needs to be performed on input that can be readily checked by
> >>> any reviewer.
> >>> The vote has to be seen to be open and complete.
> >>> The SVN (or GIT) coordinate is an essential part of the input, as it
> >>> is the only practical way to check provenance of the files in the
> >>> archives.
> >>>
> >>> Given that part of the Maven philisophy is to ensure that all plugin
> >>> versions must be specified to ensure repeatable builds, I'm a bit
> >>> surprised how much resistance there is to providing the specific
> >>> source which was used as input to the build process.
> >>>
> >>> The only change that this requires to be made to the process is to add
> >>> the revision number and tag name [1] to the release vote e-mail.
> >>> Is that really too much to ask?
> >>>
> >>> [1] A revision on its one is insufficient as the ASF uses a shared SVN
> >>> repo; the location within the tree is needed to be able to select the
> >>> revelant portion of the tree. The tag name is one such way to provide
> >>> the information.
> >>>
> >>>> Ralph
> >>>>
> >>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
> >>>>
> >>>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
> >>>>> successful tag to the GA tag.
> >>>>>
> >>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
> >>> failed release vote instead of deleting them.
> >>>>>>
> >>>>>>
> >>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >>>>>>
> >>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> >>> ralph.goers@dslextreme.com>wrote:
> >>>>>>>
> >>>>>>>> Again I have to disagree. The release manager will send an email
> >>> closing
> >>>>>>>> the prior release. At this point all the prior release artifacts
> >>> are junk
> >>>>>>>> even if they still exist. At some point the release manager will
> >>> delete
> >>>>>>>> the tag and rerun the release
> >>>>>>>
> >>>>>>>
> >>>>>>> That's a no-no IMO. Tags that have been voted on should never be
> >>> deleted.
> >>>>>>>
> >>>>>>> Gary
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> At this point the tag is still junk to everyone else because they
> >>> have no
> >>>>>>>> idea what the RM is doing - so they shouldn't be making
> assumptions
> >>> about
> >>>>>>>> non-released tags. Once he sends the email though the tag will be
> >>> valid.
> >>>>>>>> Sure having the revision number helps but unless the RM completely
> >>> screws
> >>>>>>>> up the tag should be sufficient.
> >>>>>>>>
> >>>>>>>> Ralph
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >>>>>>>>
> >>>>>>>>> Not really, no. The developer may have re-spun it again and be
> >>> about to
> >>>>>>>>> email again. You have no idea what you're looking at unless you
> >>> know the
> >>>>>>>>> revision. SVN will die off within a decade and this discussion
> will
> >>>>>>>> become
> >>>>>>>>> critical. Better to figure out how to support proper techniques
> now,
> >>>>>>>> rather
> >>>>>>>>> than wait until forced to.
> >>>>>>>>>
> >>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> >>> ralph.goers@dslextreme.com
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I disagree that the revision is required. I know that the RM is
> >>> going
> >>>>>>>> to
> >>>>>>>>>> recreate the tag with each release candidate. Therefore, so
> long
> >>> as I
> >>>>>>>>>> refetch that tag for every release vote I can be confident that
> I
> >>> am
> >>>>>>>>>> reviewing the release contents.
> >>>>>>>>>>
> >>>>>>>>>> Ralph
> >>>>>>>>>>
> >>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >>>>>>>>>>
> >>>>>>>>>>> The mission of the ASF is to release software as source, and to
> >>> ensure
> >>>>>>>>>>> that the released source is available under the Apache Licence.
> >>>>>>>>>>>
> >>>>>>>>>>> Before a release can be approved it must be voted on by the
> PMC.
> >>>>>>>>>>> The review process needs to establish that the proposed source
> >>> release
> >>>>>>>>>>> meets those aims.
> >>>>>>>>>>>
> >>>>>>>>>>> It's all but impossible for reviewers to examine every single
> >>> file in
> >>>>>>>>>>> a source archive to determine if it meets the criteria.
> >>>>>>>>>>> And it's not unknown for spurious files to creep into a release
> >>>>>>>>>>> (perhaps from a stale workspace - are releases always built
> from a
> >>>>>>>>>>> fresh checkout of the tag?)
> >>>>>>>>>>>
> >>>>>>>>>>> However, PMCs are also required to check what is added to the
> SCM
> >>>>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
> >>>>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
> >>> and
> >>>>>>>>>>> accepting new contributions.
> >>>>>>>>>>> So provided that all the files in the source release are also
> >>> present
> >>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source release
> >>> meets
> >>>>>>>>>>> the ASF criteria.
> >>>>>>>>>>>
> >>>>>>>>>>> Without having the SCM as a database of validated files, there
> >>> are far
> >>>>>>>>>>> too many files in the average source archive to check
> >>> individually.
> >>>>>>>>>>> And how would one check their provenance? The obvious way is to
> >>>>>>>>>>> compare them with the entries in SCM.
> >>>>>>>>>>>
> >>>>>>>>>>> Therefore, I contend that a release vote does not make sense
> >>> without
> >>>>>>>>>>> the SCM tag.
> >>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote
> e-mail
> >>> also
> >>>>>>>>>>> needs the revision.
> >>>>>>>>>>>
> >>>>>>>>>>> Whether every reviewer actually checks the source archive
> against
> >>> SCM
> >>>>>>>>>>> is another matter.
> >>>>>>>>>>> But if the required SCM information is not present, it would be
> >>>>>>>>>>> difficult to argue that the RM had provided sufficient
> >>> information for
> >>>>>>>>>>> a valid review to take place.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>>>>> Java Persistence with Hibernate, Second Edition<
> >>> http://www.manning.com/bauer3/>
> >>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >>>>>>> Blog: http://garygregory.wordpress.com
> >>>>>>> Home: http://garygregory.com/
> >>>>>>> Tweet! http://twitter.com/GaryGregory
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Re: Release process updates
Posted by Robert Scholte <rf...@apache.org>.
I had that idea too. 'Static' is the easy solution, 'suggest' the next
improved one :)
Robert
Op Fri, 28 Jun 2013 20:40:58 +0200 schreef Kristian Rosenvold
<kr...@gmail.com>:
> Yup, or the prepare goal actually has some kind of "auto suggest
> tagname" option; which involves scanning for existing tags according
> and proposing a new tag according to the same algorithm.
>
> So when you say you want to release foobar-1.2, it'll actually look
> for foobar-1.2§1 and auto-suggest foobar-1.2§2 as a tagame (since you
> already used foobar-1.2§1), since that's the algorithm.
>
> and of course, we need a less ridiculous separator :)
>
> Kristian
>
>
> 2013/6/28 Robert Scholte <rf...@apache.org>:
>> What we could do is adding some sort of stageTagName to the prepare
>> goal of
>> maven-release-plugin.
>> The project will initially be tagged with this value, but the pom.xml
>> still
>> contains the final tag location.
>> A new goal could be introduced where you only have to specify the
>> stagingScmUrl. The plugin can read the final destination from the
>> pom.xml
>> (or from release.properties if these are still on your system) and do
>> the
>> copy/move.
>>
>> This way we don't have to touch any of the sourcefiles, but we have to
>> accept that during staging the value of the
>> connection/developerConnection
>> does not yet match its current scm location.
>>
>> Robert
>>
>> Op Fri, 28 Jun 2013 18:22:50 +0200 schreef Kristian Rosenvold
>> <kr...@gmail.com>:
>>
>>
>>> I'll accept any separator as long as we standardize, but I do not
>>> think mixing internal project process (dealing with tags, votes and
>>> failed internal release attempts) with the final produced artifact. So
>>> IMO the project could decide to *stage* and publish foobar-1.0-rc1
>>> (which it actually promotes to maven central),
>>> but might in the release process very well make three private attempts
>>> before even rc1 is promoted.
>>>
>>> That'd make it foobar-1.0-rc§1, foobar-1.0-rc§2 and foobar-1.0-rc§3.
>>> The tags go in the poms and
>>> we just keep the final tag as a permanent reference.
>>>
>>> I'm also of the understanding that we have no legal obligation to
>>> match the source to a
>>> scm revision. But it kinda makes us look slightly more professional
>>> and I'd quite frankly
>>> find developing without source control a crazy concept; I'm sure I'd
>>> be programming php
>>> at that stage..
>>>
>>> Kristian
>>>
>>> 2013/6/28 Mirko Friedenhagen <mf...@gmail.com>:
>>>>
>>>> Kristian,
>>>>
>>>> # could lead to a lot of problems when used with dereferencing
>>>> http-proxies, because it separates the http-url fragment[1]. AFAIK
>>>> Debian packages use ~ (tilde) as separator for beta packages which has
>>>> no special semantics AFAIK in URLs.
>>>>
>>>> [1] http://en.wikipedia.org/wiki/Fragment_identifier
>>>> Regards Mirko
>>>> --
>>>> http://illegalstateexception.blogspot.com/
>>>> https://github.com/mfriedenhagen/
>>>> https://bitbucket.org/mfriedenhagen/
>>>>
>>>>
>>>> On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold
>>>> <kr...@gmail.com> wrote:
>>>>>
>>>>> This suggestion is much like what we came up with the last time
>>>>> we discussed this - about 3 weeks ago.
>>>>>
>>>>> This behaviour is simple to achieve without a single line
>>>>> of change; the release plugin already asks for a SCM tag name
>>>>> distinct from the version number. (we *could* add some kind
>>>>> of support for an explicit convention, we could even add a scm-lookup
>>>>> to auto-roll forward on subsequent takes).
>>>>>
>>>>> Now I've been trying to think if there's a sensible convention
>>>>> that could be established that would allow us to
>>>>> simply *keep* the tag name of the accepted version
>>>>> without re-pushing another tag after release (and, since the tag
>>>>> name can be etched into the pom of the released artifact, there
>>>>> should be no real reason for confusion).
>>>>>
>>>>> I've been thinking about a *tagging* convention along the lines
>>>>> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
>>>>> maven-xx-plugin-2.3.2#3..."
>>>>>
>>>>> Effectively we would delete #1 and #2 and keep the #3 tag, since this
>>>>> vote passed on take 3.
>>>>>
>>>>> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
>>>>> released 2.3.2 version.
>>>>>
>>>>> This is mostly a policy change on tag naming, we could implement this
>>>>> without a line
>>>>> of code change. Since both svn and git essentially have flawed tag
>>>>> handling it makes sense to do a change like this.
>>>>>
>>>>> Kristian
>>>>>
>>>>> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>>>>>>
>>>>>> Can you provide the steps required to get the release plugin to work
>>>>>> this way?
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> this seems to be the most popular discussion, so another 2 cents:
>>>>>>> - Today I read the man page of git-tag again.
>>>>>>> - It states very clearly you should never reuse tags, because
>>>>>>> unlike
>>>>>>> is the
>>>>>>> case with subversion, once a git tag is out in the wild (and
>>>>>>> pushing
>>>>>>> to
>>>>>>> git-wip is the jungle here), everyone who has fetched the tag would
>>>>>>> have to
>>>>>>> delete it *manually* from her copy, otherwise it will point to the
>>>>>>> wrong
>>>>>>> hash eternally.
>>>>>>>
>>>>>>> Another approach:
>>>>>>> - Always attach the rc-number to the tagname, e.g.
>>>>>>> maven-foo-2.16rc1,
>>>>>>> but
>>>>>>> *not* to the version.
>>>>>>> - *After* a successful vote create a copy of tag maven-foo-2.16rc1
>>>>>>> as
>>>>>>> maven-foo-2.16 using the SCM directly.
>>>>>>> - The version stays enduser friendly and the tag in the pom points
>>>>>>> to
>>>>>>> the
>>>>>>> sources correctly.
>>>>>>> - Diffing between different RCs and the final versions is easy.
>>>>>>> - No one has to fiddle with invalid workspaces/clones.
>>>>>>> - For the release manager it is just one additional SCM call.
>>>>>>>
>>>>>>> Regards Mirko
>>>>>>> --
>>>>>>> Sent from my mobile
>>>>>>> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> I do not believe that can be done with the release plugins as the
>>>>>>>>> pom
>>>>>>>>
>>>>>>>> has to specify the same version as the tag. If you then rename
>>>>>>>> the
>>>>>>>> tag you
>>>>>>>> would have to modify the poms in the tag, which makes the release
>>>>>>>> invalid.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Have you ever used the release plugin? If not, I would suggest
>>>>>>>>> you
>>>>>>>>> try
>>>>>>>>
>>>>>>>> it and offer up patches to change it instead of carrying on this
>>>>>>>> discussion
>>>>>>>> as it is unlikely maven is going to stop using the release plugin.
>>>>>>>>
>>>>>>>> This is straying further off the original topic.
>>>>>>>>
>>>>>>>> Whether people use the release plugin or some other method is not
>>>>>>>> really relevant to the release vote itself.
>>>>>>>>
>>>>>>>> All the process that leads up to the vote is merely a means to
>>>>>>>> trying
>>>>>>>> to ensure that the release candidate as as good as possible.
>>>>>>>>
>>>>>>>> What matters is the vote - the public declaration that the RC has
>>>>>>>> been
>>>>>>>> reviewed and approved.
>>>>>>>> Only a PMC-approved vote can get the legal protection of the ASF.
>>>>>>>>
>>>>>>>> The vote needs to be performed on input that can be readily
>>>>>>>> checked
>>>>>>>> by
>>>>>>>> any reviewer.
>>>>>>>> The vote has to be seen to be open and complete.
>>>>>>>> The SVN (or GIT) coordinate is an essential part of the input, as
>>>>>>>> it
>>>>>>>> is the only practical way to check provenance of the files in the
>>>>>>>> archives.
>>>>>>>>
>>>>>>>> Given that part of the Maven philisophy is to ensure that all
>>>>>>>> plugin
>>>>>>>> versions must be specified to ensure repeatable builds, I'm a bit
>>>>>>>> surprised how much resistance there is to providing the specific
>>>>>>>> source which was used as input to the build process.
>>>>>>>>
>>>>>>>> The only change that this requires to be made to the process is to
>>>>>>>> add
>>>>>>>> the revision number and tag name [1] to the release vote e-mail.
>>>>>>>> Is that really too much to ask?
>>>>>>>>
>>>>>>>> [1] A revision on its one is insufficient as the ASF uses a shared
>>>>>>>> SVN
>>>>>>>> repo; the location within the tree is needed to be able to select
>>>>>>>> the
>>>>>>>> revelant portion of the tree. The tag name is one such way to
>>>>>>>> provide
>>>>>>>> the information.
>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> It would be a lot better to use RC1 RC2 etc initially, and copy
>>>>>>>>>> the
>>>>>>>>>> successful tag to the GA tag.
>>>>>>>>>>
>>>>>>>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc
>>>>>>>>>>> after a
>>>>>>>>
>>>>>>>> failed release vote instead of deleting them.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>>>>>>>>
>>>>>>>> ralph.goers@dslextreme.com>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Again I have to disagree. The release manager will send an
>>>>>>>>>>>>> email
>>>>>>>>
>>>>>>>> closing
>>>>>>>>>>>>>
>>>>>>>>>>>>> the prior release. At this point all the prior release
>>>>>>>>>>>>> artifacts
>>>>>>>>
>>>>>>>> are junk
>>>>>>>>>>>>>
>>>>>>>>>>>>> even if they still exist. At some point the release manager
>>>>>>>>>>>>> will
>>>>>>>>
>>>>>>>> delete
>>>>>>>>>>>>>
>>>>>>>>>>>>> the tag and rerun the release
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That's a no-no IMO. Tags that have been voted on should never
>>>>>>>>>>>> be
>>>>>>>>
>>>>>>>> deleted.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> At this point the tag is still junk to everyone else because
>>>>>>>>>>>>> they
>>>>>>>>
>>>>>>>> have no
>>>>>>>>>>>>>
>>>>>>>>>>>>> idea what the RM is doing - so they shouldn't be making
>>>>>>>>>>>>> assumptions
>>>>>>>>
>>>>>>>> about
>>>>>>>>>>>>>
>>>>>>>>>>>>> non-released tags. Once he sends the email though the tag
>>>>>>>>>>>>> will
>>>>>>>>>>>>> be
>>>>>>>>
>>>>>>>> valid.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure having the revision number helps but unless the RM
>>>>>>>>>>>>> completely
>>>>>>>>
>>>>>>>> screws
>>>>>>>>>>>>>
>>>>>>>>>>>>> up the tag should be sufficient.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not really, no. The developer may have re-spun it again and
>>>>>>>>>>>>>> be
>>>>>>>>
>>>>>>>> about to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> email again. You have no idea what you're looking at unless
>>>>>>>>>>>>>> you
>>>>>>>>
>>>>>>>> know the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> revision. SVN will die off within a decade and this
>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>
>>>>>>>>>>>>> become
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> critical. Better to figure out how to support proper
>>>>>>>>>>>>>> techniques
>>>>>>>>>>>>>> now,
>>>>>>>>>>>>>
>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> than wait until forced to.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>>>>>>>>
>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I disagree that the revision is required. I know that the
>>>>>>>>>>>>>>> RM
>>>>>>>>>>>>>>> is
>>>>>>>>
>>>>>>>> going
>>>>>>>>>>>>>
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> recreate the tag with each release candidate. Therefore,
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> long
>>>>>>>>
>>>>>>>> as I
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> refetch that tag for every release vote I can be confident
>>>>>>>>>>>>>>> that I
>>>>>>>>
>>>>>>>> am
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> reviewing the release contents.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The mission of the ASF is to release software as source,
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> to
>>>>>>>>
>>>>>>>> ensure
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> that the released source is available under the Apache
>>>>>>>>>>>>>>>> Licence.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Before a release can be approved it must be voted on by
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> PMC.
>>>>>>>>>>>>>>>> The review process needs to establish that the proposed
>>>>>>>>>>>>>>>> source
>>>>>>>>
>>>>>>>> release
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> meets those aims.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's all but impossible for reviewers to examine every
>>>>>>>>>>>>>>>> single
>>>>>>>>
>>>>>>>> file in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>>>>>>>>> And it's not unknown for spurious files to creep into a
>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>> (perhaps from a stale workspace - are releases always
>>>>>>>>>>>>>>>> built
>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> However, PMCs are also required to check what is added to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> SCM
>>>>>>>>>>>>>>>> (SVN/Git) to make sure it meets the required license
>>>>>>>>>>>>>>>> criteria.
>>>>>>>>>>>>>>>> This is done on an ongoing basis as part of reviewing
>>>>>>>>>>>>>>>> check-ins
>>>>>>>>
>>>>>>>> and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> accepting new contributions.
>>>>>>>>>>>>>>>> So provided that all the files in the source release are
>>>>>>>>>>>>>>>> also
>>>>>>>>
>>>>>>>> present
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source
>>>>>>>>>>>>>>>> release
>>>>>>>>
>>>>>>>> meets
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the ASF criteria.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Without having the SCM as a database of validated files,
>>>>>>>>>>>>>>>> there
>>>>>>>>
>>>>>>>> are far
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> too many files in the average source archive to check
>>>>>>>>
>>>>>>>> individually.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And how would one check their provenance? The obvious way
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Therefore, I contend that a release vote does not make
>>>>>>>>>>>>>>>> sense
>>>>>>>>
>>>>>>>> without
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the SCM tag.
>>>>>>>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote
>>>>>>>>>>>>>>>> e-mail
>>>>>>>>
>>>>>>>> also
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> needs the revision.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Whether every reviewer actually checks the source archive
>>>>>>>>>>>>>>>> against
>>>>>>>>
>>>>>>>> SCM
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is another matter.
>>>>>>>>>>>>>>>> But if the required SCM information is not present, it
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> difficult to argue that the RM had provided sufficient
>>>>>>>>
>>>>>>>> information for
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> a valid review to take place.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition<
>>>>>>>>
>>>>>>>> http://www.manning.com/bauer3/>
>>>>>>>>>>>>
>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Kristian Rosenvold <kr...@gmail.com>.
Yup, or the prepare goal actually has some kind of "auto suggest
tagname" option; which involves scanning for existing tags according
and proposing a new tag according to the same algorithm.
So when you say you want to release foobar-1.2, it'll actually look
for foobar-1.2§1 and auto-suggest foobar-1.2§2 as a tagame (since you
already used foobar-1.2§1), since that's the algorithm.
and of course, we need a less ridiculous separator :)
Kristian
2013/6/28 Robert Scholte <rf...@apache.org>:
> What we could do is adding some sort of stageTagName to the prepare goal of
> maven-release-plugin.
> The project will initially be tagged with this value, but the pom.xml still
> contains the final tag location.
> A new goal could be introduced where you only have to specify the
> stagingScmUrl. The plugin can read the final destination from the pom.xml
> (or from release.properties if these are still on your system) and do the
> copy/move.
>
> This way we don't have to touch any of the sourcefiles, but we have to
> accept that during staging the value of the connection/developerConnection
> does not yet match its current scm location.
>
> Robert
>
> Op Fri, 28 Jun 2013 18:22:50 +0200 schreef Kristian Rosenvold
> <kr...@gmail.com>:
>
>
>> I'll accept any separator as long as we standardize, but I do not
>> think mixing internal project process (dealing with tags, votes and
>> failed internal release attempts) with the final produced artifact. So
>> IMO the project could decide to *stage* and publish foobar-1.0-rc1
>> (which it actually promotes to maven central),
>> but might in the release process very well make three private attempts
>> before even rc1 is promoted.
>>
>> That'd make it foobar-1.0-rc§1, foobar-1.0-rc§2 and foobar-1.0-rc§3.
>> The tags go in the poms and
>> we just keep the final tag as a permanent reference.
>>
>> I'm also of the understanding that we have no legal obligation to
>> match the source to a
>> scm revision. But it kinda makes us look slightly more professional
>> and I'd quite frankly
>> find developing without source control a crazy concept; I'm sure I'd
>> be programming php
>> at that stage..
>>
>> Kristian
>>
>> 2013/6/28 Mirko Friedenhagen <mf...@gmail.com>:
>>>
>>> Kristian,
>>>
>>> # could lead to a lot of problems when used with dereferencing
>>> http-proxies, because it separates the http-url fragment[1]. AFAIK
>>> Debian packages use ~ (tilde) as separator for beta packages which has
>>> no special semantics AFAIK in URLs.
>>>
>>> [1] http://en.wikipedia.org/wiki/Fragment_identifier
>>> Regards Mirko
>>> --
>>> http://illegalstateexception.blogspot.com/
>>> https://github.com/mfriedenhagen/
>>> https://bitbucket.org/mfriedenhagen/
>>>
>>>
>>> On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold
>>> <kr...@gmail.com> wrote:
>>>>
>>>> This suggestion is much like what we came up with the last time
>>>> we discussed this - about 3 weeks ago.
>>>>
>>>> This behaviour is simple to achieve without a single line
>>>> of change; the release plugin already asks for a SCM tag name
>>>> distinct from the version number. (we *could* add some kind
>>>> of support for an explicit convention, we could even add a scm-lookup
>>>> to auto-roll forward on subsequent takes).
>>>>
>>>> Now I've been trying to think if there's a sensible convention
>>>> that could be established that would allow us to
>>>> simply *keep* the tag name of the accepted version
>>>> without re-pushing another tag after release (and, since the tag
>>>> name can be etched into the pom of the released artifact, there
>>>> should be no real reason for confusion).
>>>>
>>>> I've been thinking about a *tagging* convention along the lines
>>>> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
>>>> maven-xx-plugin-2.3.2#3..."
>>>>
>>>> Effectively we would delete #1 and #2 and keep the #3 tag, since this
>>>> vote passed on take 3.
>>>>
>>>> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
>>>> released 2.3.2 version.
>>>>
>>>> This is mostly a policy change on tag naming, we could implement this
>>>> without a line
>>>> of code change. Since both svn and git essentially have flawed tag
>>>> handling it makes sense to do a change like this.
>>>>
>>>> Kristian
>>>>
>>>> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>>>>>
>>>>> Can you provide the steps required to get the release plugin to work
>>>>> this way?
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> this seems to be the most popular discussion, so another 2 cents:
>>>>>> - Today I read the man page of git-tag again.
>>>>>> - It states very clearly you should never reuse tags, because unlike
>>>>>> is the
>>>>>> case with subversion, once a git tag is out in the wild (and pushing
>>>>>> to
>>>>>> git-wip is the jungle here), everyone who has fetched the tag would
>>>>>> have to
>>>>>> delete it *manually* from her copy, otherwise it will point to the
>>>>>> wrong
>>>>>> hash eternally.
>>>>>>
>>>>>> Another approach:
>>>>>> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1,
>>>>>> but
>>>>>> *not* to the version.
>>>>>> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
>>>>>> maven-foo-2.16 using the SCM directly.
>>>>>> - The version stays enduser friendly and the tag in the pom points to
>>>>>> the
>>>>>> sources correctly.
>>>>>> - Diffing between different RCs and the final versions is easy.
>>>>>> - No one has to fiddle with invalid workspaces/clones.
>>>>>> - For the release manager it is just one additional SCM call.
>>>>>>
>>>>>> Regards Mirko
>>>>>> --
>>>>>> Sent from my mobile
>>>>>> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>>>>>>
>>>>>>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>>>>>>>>
>>>>>>>> I do not believe that can be done with the release plugins as the
>>>>>>>> pom
>>>>>>>
>>>>>>> has to specify the same version as the tag. If you then rename the
>>>>>>> tag you
>>>>>>> would have to modify the poms in the tag, which makes the release
>>>>>>> invalid.
>>>>>>>>
>>>>>>>>
>>>>>>>> Have you ever used the release plugin? If not, I would suggest you
>>>>>>>> try
>>>>>>>
>>>>>>> it and offer up patches to change it instead of carrying on this
>>>>>>> discussion
>>>>>>> as it is unlikely maven is going to stop using the release plugin.
>>>>>>>
>>>>>>> This is straying further off the original topic.
>>>>>>>
>>>>>>> Whether people use the release plugin or some other method is not
>>>>>>> really relevant to the release vote itself.
>>>>>>>
>>>>>>> All the process that leads up to the vote is merely a means to trying
>>>>>>> to ensure that the release candidate as as good as possible.
>>>>>>>
>>>>>>> What matters is the vote - the public declaration that the RC has
>>>>>>> been
>>>>>>> reviewed and approved.
>>>>>>> Only a PMC-approved vote can get the legal protection of the ASF.
>>>>>>>
>>>>>>> The vote needs to be performed on input that can be readily checked
>>>>>>> by
>>>>>>> any reviewer.
>>>>>>> The vote has to be seen to be open and complete.
>>>>>>> The SVN (or GIT) coordinate is an essential part of the input, as it
>>>>>>> is the only practical way to check provenance of the files in the
>>>>>>> archives.
>>>>>>>
>>>>>>> Given that part of the Maven philisophy is to ensure that all plugin
>>>>>>> versions must be specified to ensure repeatable builds, I'm a bit
>>>>>>> surprised how much resistance there is to providing the specific
>>>>>>> source which was used as input to the build process.
>>>>>>>
>>>>>>> The only change that this requires to be made to the process is to
>>>>>>> add
>>>>>>> the revision number and tag name [1] to the release vote e-mail.
>>>>>>> Is that really too much to ask?
>>>>>>>
>>>>>>> [1] A revision on its one is insufficient as the ASF uses a shared
>>>>>>> SVN
>>>>>>> repo; the location within the tree is needed to be able to select the
>>>>>>> revelant portion of the tree. The tag name is one such way to provide
>>>>>>> the information.
>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>>>>>>>>> successful tag to the GA tag.
>>>>>>>>>
>>>>>>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>>>>>>>
>>>>>>> failed release vote instead of deleting them.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>>>>>>>
>>>>>>> ralph.goers@dslextreme.com>wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Again I have to disagree. The release manager will send an
>>>>>>>>>>>> email
>>>>>>>
>>>>>>> closing
>>>>>>>>>>>>
>>>>>>>>>>>> the prior release. At this point all the prior release
>>>>>>>>>>>> artifacts
>>>>>>>
>>>>>>> are junk
>>>>>>>>>>>>
>>>>>>>>>>>> even if they still exist. At some point the release manager
>>>>>>>>>>>> will
>>>>>>>
>>>>>>> delete
>>>>>>>>>>>>
>>>>>>>>>>>> the tag and rerun the release
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That's a no-no IMO. Tags that have been voted on should never be
>>>>>>>
>>>>>>> deleted.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> At this point the tag is still junk to everyone else because
>>>>>>>>>>>> they
>>>>>>>
>>>>>>> have no
>>>>>>>>>>>>
>>>>>>>>>>>> idea what the RM is doing - so they shouldn't be making
>>>>>>>>>>>> assumptions
>>>>>>>
>>>>>>> about
>>>>>>>>>>>>
>>>>>>>>>>>> non-released tags. Once he sends the email though the tag will
>>>>>>>>>>>> be
>>>>>>>
>>>>>>> valid.
>>>>>>>>>>>>
>>>>>>>>>>>> Sure having the revision number helps but unless the RM
>>>>>>>>>>>> completely
>>>>>>>
>>>>>>> screws
>>>>>>>>>>>>
>>>>>>>>>>>> up the tag should be sufficient.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Not really, no. The developer may have re-spun it again and be
>>>>>>>
>>>>>>> about to
>>>>>>>>>>>>>
>>>>>>>>>>>>> email again. You have no idea what you're looking at unless you
>>>>>>>
>>>>>>> know the
>>>>>>>>>>>>>
>>>>>>>>>>>>> revision. SVN will die off within a decade and this discussion
>>>>>>>>>>>>> will
>>>>>>>>>>>>
>>>>>>>>>>>> become
>>>>>>>>>>>>>
>>>>>>>>>>>>> critical. Better to figure out how to support proper techniques
>>>>>>>>>>>>> now,
>>>>>>>>>>>>
>>>>>>>>>>>> rather
>>>>>>>>>>>>>
>>>>>>>>>>>>> than wait until forced to.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>>>>>>>
>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I disagree that the revision is required. I know that the RM
>>>>>>>>>>>>>> is
>>>>>>>
>>>>>>> going
>>>>>>>>>>>>
>>>>>>>>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> recreate the tag with each release candidate. Therefore, so
>>>>>>>>>>>>>> long
>>>>>>>
>>>>>>> as I
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> refetch that tag for every release vote I can be confident
>>>>>>>>>>>>>> that I
>>>>>>>
>>>>>>> am
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> reviewing the release contents.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The mission of the ASF is to release software as source, and
>>>>>>>>>>>>>>> to
>>>>>>>
>>>>>>> ensure
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> that the released source is available under the Apache
>>>>>>>>>>>>>>> Licence.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Before a release can be approved it must be voted on by the
>>>>>>>>>>>>>>> PMC.
>>>>>>>>>>>>>>> The review process needs to establish that the proposed
>>>>>>>>>>>>>>> source
>>>>>>>
>>>>>>> release
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> meets those aims.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It's all but impossible for reviewers to examine every single
>>>>>>>
>>>>>>> file in
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>>>>>>>> And it's not unknown for spurious files to creep into a
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> (perhaps from a stale workspace - are releases always built
>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, PMCs are also required to check what is added to the
>>>>>>>>>>>>>>> SCM
>>>>>>>>>>>>>>> (SVN/Git) to make sure it meets the required license
>>>>>>>>>>>>>>> criteria.
>>>>>>>>>>>>>>> This is done on an ongoing basis as part of reviewing
>>>>>>>>>>>>>>> check-ins
>>>>>>>
>>>>>>> and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> accepting new contributions.
>>>>>>>>>>>>>>> So provided that all the files in the source release are also
>>>>>>>
>>>>>>> present
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source
>>>>>>>>>>>>>>> release
>>>>>>>
>>>>>>> meets
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the ASF criteria.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Without having the SCM as a database of validated files,
>>>>>>>>>>>>>>> there
>>>>>>>
>>>>>>> are far
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> too many files in the average source archive to check
>>>>>>>
>>>>>>> individually.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And how would one check their provenance? The obvious way is
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Therefore, I contend that a release vote does not make sense
>>>>>>>
>>>>>>> without
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the SCM tag.
>>>>>>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote
>>>>>>>>>>>>>>> e-mail
>>>>>>>
>>>>>>> also
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> needs the revision.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Whether every reviewer actually checks the source archive
>>>>>>>>>>>>>>> against
>>>>>>>
>>>>>>> SCM
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is another matter.
>>>>>>>>>>>>>>> But if the required SCM information is not present, it would
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> difficult to argue that the RM had provided sufficient
>>>>>>>
>>>>>>> information for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a valid review to take place.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>> Java Persistence with Hibernate, Second Edition<
>>>>>>>
>>>>>>> http://www.manning.com/bauer3/>
>>>>>>>>>>>
>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Robert Scholte <rf...@apache.org>.
What we could do is adding some sort of stageTagName to the prepare goal
of maven-release-plugin.
The project will initially be tagged with this value, but the pom.xml
still contains the final tag location.
A new goal could be introduced where you only have to specify the
stagingScmUrl. The plugin can read the final destination from the pom.xml
(or from release.properties if these are still on your system) and do the
copy/move.
This way we don't have to touch any of the sourcefiles, but we have to
accept that during staging the value of the connection/developerConnection
does not yet match its current scm location.
Robert
Op Fri, 28 Jun 2013 18:22:50 +0200 schreef Kristian Rosenvold
<kr...@gmail.com>:
> I'll accept any separator as long as we standardize, but I do not
> think mixing internal project process (dealing with tags, votes and
> failed internal release attempts) with the final produced artifact. So
> IMO the project could decide to *stage* and publish foobar-1.0-rc1
> (which it actually promotes to maven central),
> but might in the release process very well make three private attempts
> before even rc1 is promoted.
>
> That'd make it foobar-1.0-rc§1, foobar-1.0-rc§2 and foobar-1.0-rc§3.
> The tags go in the poms and
> we just keep the final tag as a permanent reference.
>
> I'm also of the understanding that we have no legal obligation to
> match the source to a
> scm revision. But it kinda makes us look slightly more professional
> and I'd quite frankly
> find developing without source control a crazy concept; I'm sure I'd
> be programming php
> at that stage..
>
> Kristian
>
> 2013/6/28 Mirko Friedenhagen <mf...@gmail.com>:
>> Kristian,
>>
>> # could lead to a lot of problems when used with dereferencing
>> http-proxies, because it separates the http-url fragment[1]. AFAIK
>> Debian packages use ~ (tilde) as separator for beta packages which has
>> no special semantics AFAIK in URLs.
>>
>> [1] http://en.wikipedia.org/wiki/Fragment_identifier
>> Regards Mirko
>> --
>> http://illegalstateexception.blogspot.com/
>> https://github.com/mfriedenhagen/
>> https://bitbucket.org/mfriedenhagen/
>>
>>
>> On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold
>> <kr...@gmail.com> wrote:
>>> This suggestion is much like what we came up with the last time
>>> we discussed this - about 3 weeks ago.
>>>
>>> This behaviour is simple to achieve without a single line
>>> of change; the release plugin already asks for a SCM tag name
>>> distinct from the version number. (we *could* add some kind
>>> of support for an explicit convention, we could even add a scm-lookup
>>> to auto-roll forward on subsequent takes).
>>>
>>> Now I've been trying to think if there's a sensible convention
>>> that could be established that would allow us to
>>> simply *keep* the tag name of the accepted version
>>> without re-pushing another tag after release (and, since the tag
>>> name can be etched into the pom of the released artifact, there
>>> should be no real reason for confusion).
>>>
>>> I've been thinking about a *tagging* convention along the lines
>>> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
>>> maven-xx-plugin-2.3.2#3..."
>>>
>>> Effectively we would delete #1 and #2 and keep the #3 tag, since this
>>> vote passed on take 3.
>>>
>>> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
>>> released 2.3.2 version.
>>>
>>> This is mostly a policy change on tag naming, we could implement this
>>> without a line
>>> of code change. Since both svn and git essentially have flawed tag
>>> handling it makes sense to do a change like this.
>>>
>>> Kristian
>>>
>>> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>>>> Can you provide the steps required to get the release plugin to work
>>>> this way?
>>>>
>>>> Ralph
>>>>
>>>> On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> this seems to be the most popular discussion, so another 2 cents:
>>>>> - Today I read the man page of git-tag again.
>>>>> - It states very clearly you should never reuse tags, because unlike
>>>>> is the
>>>>> case with subversion, once a git tag is out in the wild (and pushing
>>>>> to
>>>>> git-wip is the jungle here), everyone who has fetched the tag would
>>>>> have to
>>>>> delete it *manually* from her copy, otherwise it will point to the
>>>>> wrong
>>>>> hash eternally.
>>>>>
>>>>> Another approach:
>>>>> - Always attach the rc-number to the tagname, e.g.
>>>>> maven-foo-2.16rc1, but
>>>>> *not* to the version.
>>>>> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
>>>>> maven-foo-2.16 using the SCM directly.
>>>>> - The version stays enduser friendly and the tag in the pom points
>>>>> to the
>>>>> sources correctly.
>>>>> - Diffing between different RCs and the final versions is easy.
>>>>> - No one has to fiddle with invalid workspaces/clones.
>>>>> - For the release manager it is just one additional SCM call.
>>>>>
>>>>> Regards Mirko
>>>>> --
>>>>> Sent from my mobile
>>>>> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>>>>>
>>>>>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>>>>>>> I do not believe that can be done with the release plugins as the
>>>>>>> pom
>>>>>> has to specify the same version as the tag. If you then rename the
>>>>>> tag you
>>>>>> would have to modify the poms in the tag, which makes the release
>>>>>> invalid.
>>>>>>>
>>>>>>> Have you ever used the release plugin? If not, I would suggest
>>>>>>> you try
>>>>>> it and offer up patches to change it instead of carrying on this
>>>>>> discussion
>>>>>> as it is unlikely maven is going to stop using the release plugin.
>>>>>>
>>>>>> This is straying further off the original topic.
>>>>>>
>>>>>> Whether people use the release plugin or some other method is not
>>>>>> really relevant to the release vote itself.
>>>>>>
>>>>>> All the process that leads up to the vote is merely a means to
>>>>>> trying
>>>>>> to ensure that the release candidate as as good as possible.
>>>>>>
>>>>>> What matters is the vote - the public declaration that the RC has
>>>>>> been
>>>>>> reviewed and approved.
>>>>>> Only a PMC-approved vote can get the legal protection of the ASF.
>>>>>>
>>>>>> The vote needs to be performed on input that can be readily checked
>>>>>> by
>>>>>> any reviewer.
>>>>>> The vote has to be seen to be open and complete.
>>>>>> The SVN (or GIT) coordinate is an essential part of the input, as it
>>>>>> is the only practical way to check provenance of the files in the
>>>>>> archives.
>>>>>>
>>>>>> Given that part of the Maven philisophy is to ensure that all plugin
>>>>>> versions must be specified to ensure repeatable builds, I'm a bit
>>>>>> surprised how much resistance there is to providing the specific
>>>>>> source which was used as input to the build process.
>>>>>>
>>>>>> The only change that this requires to be made to the process is to
>>>>>> add
>>>>>> the revision number and tag name [1] to the release vote e-mail.
>>>>>> Is that really too much to ask?
>>>>>>
>>>>>> [1] A revision on its one is insufficient as the ASF uses a shared
>>>>>> SVN
>>>>>> repo; the location within the tree is needed to be able to select
>>>>>> the
>>>>>> revelant portion of the tree. The tag name is one such way to
>>>>>> provide
>>>>>> the information.
>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>>> It would be a lot better to use RC1 RC2 etc initially, and copy
>>>>>>>> the
>>>>>>>> successful tag to the GA tag.
>>>>>>>>
>>>>>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>>>>>> failed release vote instead of deleting them.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>>>>>> ralph.goers@dslextreme.com>wrote:
>>>>>>>>>>
>>>>>>>>>>> Again I have to disagree. The release manager will send an
>>>>>>>>>>> email
>>>>>> closing
>>>>>>>>>>> the prior release. At this point all the prior release
>>>>>>>>>>> artifacts
>>>>>> are junk
>>>>>>>>>>> even if they still exist. At some point the release manager
>>>>>>>>>>> will
>>>>>> delete
>>>>>>>>>>> the tag and rerun the release
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That's a no-no IMO. Tags that have been voted on should never be
>>>>>> deleted.
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> At this point the tag is still junk to everyone else because
>>>>>>>>>>> they
>>>>>> have no
>>>>>>>>>>> idea what the RM is doing - so they shouldn't be making
>>>>>>>>>>> assumptions
>>>>>> about
>>>>>>>>>>> non-released tags. Once he sends the email though the tag
>>>>>>>>>>> will be
>>>>>> valid.
>>>>>>>>>>> Sure having the revision number helps but unless the RM
>>>>>>>>>>> completely
>>>>>> screws
>>>>>>>>>>> up the tag should be sufficient.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Not really, no. The developer may have re-spun it again and be
>>>>>> about to
>>>>>>>>>>>> email again. You have no idea what you're looking at unless
>>>>>>>>>>>> you
>>>>>> know the
>>>>>>>>>>>> revision. SVN will die off within a decade and this
>>>>>>>>>>>> discussion will
>>>>>>>>>>> become
>>>>>>>>>>>> critical. Better to figure out how to support proper
>>>>>>>>>>>> techniques now,
>>>>>>>>>>> rather
>>>>>>>>>>>> than wait until forced to.
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I disagree that the revision is required. I know that the
>>>>>>>>>>>>> RM is
>>>>>> going
>>>>>>>>>>> to
>>>>>>>>>>>>> recreate the tag with each release candidate. Therefore, so
>>>>>>>>>>>>> long
>>>>>> as I
>>>>>>>>>>>>> refetch that tag for every release vote I can be confident
>>>>>>>>>>>>> that I
>>>>>> am
>>>>>>>>>>>>> reviewing the release contents.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The mission of the ASF is to release software as source,
>>>>>>>>>>>>>> and to
>>>>>> ensure
>>>>>>>>>>>>>> that the released source is available under the Apache
>>>>>>>>>>>>>> Licence.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Before a release can be approved it must be voted on by the
>>>>>>>>>>>>>> PMC.
>>>>>>>>>>>>>> The review process needs to establish that the proposed
>>>>>>>>>>>>>> source
>>>>>> release
>>>>>>>>>>>>>> meets those aims.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's all but impossible for reviewers to examine every
>>>>>>>>>>>>>> single
>>>>>> file in
>>>>>>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>>>>>>> And it's not unknown for spurious files to creep into a
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>> (perhaps from a stale workspace - are releases always built
>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, PMCs are also required to check what is added to
>>>>>>>>>>>>>> the SCM
>>>>>>>>>>>>>> (SVN/Git) to make sure it meets the required license
>>>>>>>>>>>>>> criteria.
>>>>>>>>>>>>>> This is done on an ongoing basis as part of reviewing
>>>>>>>>>>>>>> check-ins
>>>>>> and
>>>>>>>>>>>>>> accepting new contributions.
>>>>>>>>>>>>>> So provided that all the files in the source release are
>>>>>>>>>>>>>> also
>>>>>> present
>>>>>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source
>>>>>>>>>>>>>> release
>>>>>> meets
>>>>>>>>>>>>>> the ASF criteria.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Without having the SCM as a database of validated files,
>>>>>>>>>>>>>> there
>>>>>> are far
>>>>>>>>>>>>>> too many files in the average source archive to check
>>>>>> individually.
>>>>>>>>>>>>>> And how would one check their provenance? The obvious way
>>>>>>>>>>>>>> is to
>>>>>>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Therefore, I contend that a release vote does not make sense
>>>>>> without
>>>>>>>>>>>>>> the SCM tag.
>>>>>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote
>>>>>>>>>>>>>> e-mail
>>>>>> also
>>>>>>>>>>>>>> needs the revision.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Whether every reviewer actually checks the source archive
>>>>>>>>>>>>>> against
>>>>>> SCM
>>>>>>>>>>>>>> is another matter.
>>>>>>>>>>>>>> But if the required SCM information is not present, it
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> difficult to argue that the RM had provided sufficient
>>>>>> information for
>>>>>>>>>>>>>> a valid review to take place.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> Java Persistence with Hibernate, Second Edition<
>>>>>> http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Kristian Rosenvold <kr...@gmail.com>.
I'll accept any separator as long as we standardize, but I do not
think mixing internal project process (dealing with tags, votes and
failed internal release attempts) with the final produced artifact. So
IMO the project could decide to *stage* and publish foobar-1.0-rc1
(which it actually promotes to maven central),
but might in the release process very well make three private attempts
before even rc1 is promoted.
That'd make it foobar-1.0-rc§1, foobar-1.0-rc§2 and foobar-1.0-rc§3.
The tags go in the poms and
we just keep the final tag as a permanent reference.
I'm also of the understanding that we have no legal obligation to
match the source to a
scm revision. But it kinda makes us look slightly more professional
and I'd quite frankly
find developing without source control a crazy concept; I'm sure I'd
be programming php
at that stage..
Kristian
2013/6/28 Mirko Friedenhagen <mf...@gmail.com>:
> Kristian,
>
> # could lead to a lot of problems when used with dereferencing
> http-proxies, because it separates the http-url fragment[1]. AFAIK
> Debian packages use ~ (tilde) as separator for beta packages which has
> no special semantics AFAIK in URLs.
>
> [1] http://en.wikipedia.org/wiki/Fragment_identifier
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/
> https://bitbucket.org/mfriedenhagen/
>
>
> On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold
> <kr...@gmail.com> wrote:
>> This suggestion is much like what we came up with the last time
>> we discussed this - about 3 weeks ago.
>>
>> This behaviour is simple to achieve without a single line
>> of change; the release plugin already asks for a SCM tag name
>> distinct from the version number. (we *could* add some kind
>> of support for an explicit convention, we could even add a scm-lookup
>> to auto-roll forward on subsequent takes).
>>
>> Now I've been trying to think if there's a sensible convention
>> that could be established that would allow us to
>> simply *keep* the tag name of the accepted version
>> without re-pushing another tag after release (and, since the tag
>> name can be etched into the pom of the released artifact, there
>> should be no real reason for confusion).
>>
>> I've been thinking about a *tagging* convention along the lines
>> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
>> maven-xx-plugin-2.3.2#3..."
>>
>> Effectively we would delete #1 and #2 and keep the #3 tag, since this
>> vote passed on take 3.
>>
>> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
>> released 2.3.2 version.
>>
>> This is mostly a policy change on tag naming, we could implement this
>> without a line
>> of code change. Since both svn and git essentially have flawed tag
>> handling it makes sense to do a change like this.
>>
>> Kristian
>>
>> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>>> Can you provide the steps required to get the release plugin to work this way?
>>>
>>> Ralph
>>>
>>> On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>>>
>>>> Hello,
>>>>
>>>> this seems to be the most popular discussion, so another 2 cents:
>>>> - Today I read the man page of git-tag again.
>>>> - It states very clearly you should never reuse tags, because unlike is the
>>>> case with subversion, once a git tag is out in the wild (and pushing to
>>>> git-wip is the jungle here), everyone who has fetched the tag would have to
>>>> delete it *manually* from her copy, otherwise it will point to the wrong
>>>> hash eternally.
>>>>
>>>> Another approach:
>>>> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1, but
>>>> *not* to the version.
>>>> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
>>>> maven-foo-2.16 using the SCM directly.
>>>> - The version stays enduser friendly and the tag in the pom points to the
>>>> sources correctly.
>>>> - Diffing between different RCs and the final versions is easy.
>>>> - No one has to fiddle with invalid workspaces/clones.
>>>> - For the release manager it is just one additional SCM call.
>>>>
>>>> Regards Mirko
>>>> --
>>>> Sent from my mobile
>>>> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>>>>
>>>>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>>>>>> I do not believe that can be done with the release plugins as the pom
>>>>> has to specify the same version as the tag. If you then rename the tag you
>>>>> would have to modify the poms in the tag, which makes the release invalid.
>>>>>>
>>>>>> Have you ever used the release plugin? If not, I would suggest you try
>>>>> it and offer up patches to change it instead of carrying on this discussion
>>>>> as it is unlikely maven is going to stop using the release plugin.
>>>>>
>>>>> This is straying further off the original topic.
>>>>>
>>>>> Whether people use the release plugin or some other method is not
>>>>> really relevant to the release vote itself.
>>>>>
>>>>> All the process that leads up to the vote is merely a means to trying
>>>>> to ensure that the release candidate as as good as possible.
>>>>>
>>>>> What matters is the vote - the public declaration that the RC has been
>>>>> reviewed and approved.
>>>>> Only a PMC-approved vote can get the legal protection of the ASF.
>>>>>
>>>>> The vote needs to be performed on input that can be readily checked by
>>>>> any reviewer.
>>>>> The vote has to be seen to be open and complete.
>>>>> The SVN (or GIT) coordinate is an essential part of the input, as it
>>>>> is the only practical way to check provenance of the files in the
>>>>> archives.
>>>>>
>>>>> Given that part of the Maven philisophy is to ensure that all plugin
>>>>> versions must be specified to ensure repeatable builds, I'm a bit
>>>>> surprised how much resistance there is to providing the specific
>>>>> source which was used as input to the build process.
>>>>>
>>>>> The only change that this requires to be made to the process is to add
>>>>> the revision number and tag name [1] to the release vote e-mail.
>>>>> Is that really too much to ask?
>>>>>
>>>>> [1] A revision on its one is insufficient as the ASF uses a shared SVN
>>>>> repo; the location within the tree is needed to be able to select the
>>>>> revelant portion of the tree. The tag name is one such way to provide
>>>>> the information.
>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>>>>>>> successful tag to the GA tag.
>>>>>>>
>>>>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>>>>> failed release vote instead of deleting them.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>>>>>
>>>>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com>wrote:
>>>>>>>>>
>>>>>>>>>> Again I have to disagree. The release manager will send an email
>>>>> closing
>>>>>>>>>> the prior release. At this point all the prior release artifacts
>>>>> are junk
>>>>>>>>>> even if they still exist. At some point the release manager will
>>>>> delete
>>>>>>>>>> the tag and rerun the release
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That's a no-no IMO. Tags that have been voted on should never be
>>>>> deleted.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> At this point the tag is still junk to everyone else because they
>>>>> have no
>>>>>>>>>> idea what the RM is doing - so they shouldn't be making assumptions
>>>>> about
>>>>>>>>>> non-released tags. Once he sends the email though the tag will be
>>>>> valid.
>>>>>>>>>> Sure having the revision number helps but unless the RM completely
>>>>> screws
>>>>>>>>>> up the tag should be sufficient.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>>>>>
>>>>>>>>>>> Not really, no. The developer may have re-spun it again and be
>>>>> about to
>>>>>>>>>>> email again. You have no idea what you're looking at unless you
>>>>> know the
>>>>>>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>>>>>>> become
>>>>>>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>>>>>>> rather
>>>>>>>>>>> than wait until forced to.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I disagree that the revision is required. I know that the RM is
>>>>> going
>>>>>>>>>> to
>>>>>>>>>>>> recreate the tag with each release candidate. Therefore, so long
>>>>> as I
>>>>>>>>>>>> refetch that tag for every release vote I can be confident that I
>>>>> am
>>>>>>>>>>>> reviewing the release contents.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> The mission of the ASF is to release software as source, and to
>>>>> ensure
>>>>>>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>>>>>>>> The review process needs to establish that the proposed source
>>>>> release
>>>>>>>>>>>>> meets those aims.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's all but impossible for reviewers to examine every single
>>>>> file in
>>>>>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
>>>>> and
>>>>>>>>>>>>> accepting new contributions.
>>>>>>>>>>>>> So provided that all the files in the source release are also
>>>>> present
>>>>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source release
>>>>> meets
>>>>>>>>>>>>> the ASF criteria.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Without having the SCM as a database of validated files, there
>>>>> are far
>>>>>>>>>>>>> too many files in the average source archive to check
>>>>> individually.
>>>>>>>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Therefore, I contend that a release vote does not make sense
>>>>> without
>>>>>>>>>>>>> the SCM tag.
>>>>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
>>>>> also
>>>>>>>>>>>>> needs the revision.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Whether every reviewer actually checks the source archive against
>>>>> SCM
>>>>>>>>>>>>> is another matter.
>>>>>>>>>>>>> But if the required SCM information is not present, it would be
>>>>>>>>>>>>> difficult to argue that the RM had provided sufficient
>>>>> information for
>>>>>>>>>>>>> a valid review to take place.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> Java Persistence with Hibernate, Second Edition<
>>>>> http://www.manning.com/bauer3/>
>>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Kristian,
# could lead to a lot of problems when used with dereferencing
http-proxies, because it separates the http-url fragment[1]. AFAIK
Debian packages use ~ (tilde) as separator for beta packages which has
no special semantics AFAIK in URLs.
[1] http://en.wikipedia.org/wiki/Fragment_identifier
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold
<kr...@gmail.com> wrote:
> This suggestion is much like what we came up with the last time
> we discussed this - about 3 weeks ago.
>
> This behaviour is simple to achieve without a single line
> of change; the release plugin already asks for a SCM tag name
> distinct from the version number. (we *could* add some kind
> of support for an explicit convention, we could even add a scm-lookup
> to auto-roll forward on subsequent takes).
>
> Now I've been trying to think if there's a sensible convention
> that could be established that would allow us to
> simply *keep* the tag name of the accepted version
> without re-pushing another tag after release (and, since the tag
> name can be etched into the pom of the released artifact, there
> should be no real reason for confusion).
>
> I've been thinking about a *tagging* convention along the lines
> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
> maven-xx-plugin-2.3.2#3..."
>
> Effectively we would delete #1 and #2 and keep the #3 tag, since this
> vote passed on take 3.
>
> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
> released 2.3.2 version.
>
> This is mostly a policy change on tag naming, we could implement this
> without a line
> of code change. Since both svn and git essentially have flawed tag
> handling it makes sense to do a change like this.
>
> Kristian
>
> 2013/6/28 Ralph Goers <ra...@dslextreme.com>:
>> Can you provide the steps required to get the release plugin to work this way?
>>
>> Ralph
>>
>> On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>>
>>> Hello,
>>>
>>> this seems to be the most popular discussion, so another 2 cents:
>>> - Today I read the man page of git-tag again.
>>> - It states very clearly you should never reuse tags, because unlike is the
>>> case with subversion, once a git tag is out in the wild (and pushing to
>>> git-wip is the jungle here), everyone who has fetched the tag would have to
>>> delete it *manually* from her copy, otherwise it will point to the wrong
>>> hash eternally.
>>>
>>> Another approach:
>>> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1, but
>>> *not* to the version.
>>> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
>>> maven-foo-2.16 using the SCM directly.
>>> - The version stays enduser friendly and the tag in the pom points to the
>>> sources correctly.
>>> - Diffing between different RCs and the final versions is easy.
>>> - No one has to fiddle with invalid workspaces/clones.
>>> - For the release manager it is just one additional SCM call.
>>>
>>> Regards Mirko
>>> --
>>> Sent from my mobile
>>> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>>>
>>>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>>>>> I do not believe that can be done with the release plugins as the pom
>>>> has to specify the same version as the tag. If you then rename the tag you
>>>> would have to modify the poms in the tag, which makes the release invalid.
>>>>>
>>>>> Have you ever used the release plugin? If not, I would suggest you try
>>>> it and offer up patches to change it instead of carrying on this discussion
>>>> as it is unlikely maven is going to stop using the release plugin.
>>>>
>>>> This is straying further off the original topic.
>>>>
>>>> Whether people use the release plugin or some other method is not
>>>> really relevant to the release vote itself.
>>>>
>>>> All the process that leads up to the vote is merely a means to trying
>>>> to ensure that the release candidate as as good as possible.
>>>>
>>>> What matters is the vote - the public declaration that the RC has been
>>>> reviewed and approved.
>>>> Only a PMC-approved vote can get the legal protection of the ASF.
>>>>
>>>> The vote needs to be performed on input that can be readily checked by
>>>> any reviewer.
>>>> The vote has to be seen to be open and complete.
>>>> The SVN (or GIT) coordinate is an essential part of the input, as it
>>>> is the only practical way to check provenance of the files in the
>>>> archives.
>>>>
>>>> Given that part of the Maven philisophy is to ensure that all plugin
>>>> versions must be specified to ensure repeatable builds, I'm a bit
>>>> surprised how much resistance there is to providing the specific
>>>> source which was used as input to the build process.
>>>>
>>>> The only change that this requires to be made to the process is to add
>>>> the revision number and tag name [1] to the release vote e-mail.
>>>> Is that really too much to ask?
>>>>
>>>> [1] A revision on its one is insufficient as the ASF uses a shared SVN
>>>> repo; the location within the tree is needed to be able to select the
>>>> revelant portion of the tree. The tag name is one such way to provide
>>>> the information.
>>>>
>>>>> Ralph
>>>>>
>>>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>>>>>> successful tag to the GA tag.
>>>>>>
>>>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>>>> failed release vote instead of deleting them.
>>>>>>>
>>>>>>>
>>>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>>>>
>>>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>>>> ralph.goers@dslextreme.com>wrote:
>>>>>>>>
>>>>>>>>> Again I have to disagree. The release manager will send an email
>>>> closing
>>>>>>>>> the prior release. At this point all the prior release artifacts
>>>> are junk
>>>>>>>>> even if they still exist. At some point the release manager will
>>>> delete
>>>>>>>>> the tag and rerun the release
>>>>>>>>
>>>>>>>>
>>>>>>>> That's a no-no IMO. Tags that have been voted on should never be
>>>> deleted.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> At this point the tag is still junk to everyone else because they
>>>> have no
>>>>>>>>> idea what the RM is doing - so they shouldn't be making assumptions
>>>> about
>>>>>>>>> non-released tags. Once he sends the email though the tag will be
>>>> valid.
>>>>>>>>> Sure having the revision number helps but unless the RM completely
>>>> screws
>>>>>>>>> up the tag should be sufficient.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>>>>
>>>>>>>>>> Not really, no. The developer may have re-spun it again and be
>>>> about to
>>>>>>>>>> email again. You have no idea what you're looking at unless you
>>>> know the
>>>>>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>>>>>> become
>>>>>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>>>>>> rather
>>>>>>>>>> than wait until forced to.
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>>>> ralph.goers@dslextreme.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I disagree that the revision is required. I know that the RM is
>>>> going
>>>>>>>>> to
>>>>>>>>>>> recreate the tag with each release candidate. Therefore, so long
>>>> as I
>>>>>>>>>>> refetch that tag for every release vote I can be confident that I
>>>> am
>>>>>>>>>>> reviewing the release contents.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>>>>
>>>>>>>>>>>> The mission of the ASF is to release software as source, and to
>>>> ensure
>>>>>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>>>>>
>>>>>>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>>>>>>> The review process needs to establish that the proposed source
>>>> release
>>>>>>>>>>>> meets those aims.
>>>>>>>>>>>>
>>>>>>>>>>>> It's all but impossible for reviewers to examine every single
>>>> file in
>>>>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>>>>
>>>>>>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
>>>> and
>>>>>>>>>>>> accepting new contributions.
>>>>>>>>>>>> So provided that all the files in the source release are also
>>>> present
>>>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source release
>>>> meets
>>>>>>>>>>>> the ASF criteria.
>>>>>>>>>>>>
>>>>>>>>>>>> Without having the SCM as a database of validated files, there
>>>> are far
>>>>>>>>>>>> too many files in the average source archive to check
>>>> individually.
>>>>>>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>>>>
>>>>>>>>>>>> Therefore, I contend that a release vote does not make sense
>>>> without
>>>>>>>>>>>> the SCM tag.
>>>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
>>>> also
>>>>>>>>>>>> needs the revision.
>>>>>>>>>>>>
>>>>>>>>>>>> Whether every reviewer actually checks the source archive against
>>>> SCM
>>>>>>>>>>>> is another matter.
>>>>>>>>>>>> But if the required SCM information is not present, it would be
>>>>>>>>>>>> difficult to argue that the RM had provided sufficient
>>>> information for
>>>>>>>>>>>> a valid review to take place.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> Java Persistence with Hibernate, Second Edition<
>>>> http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Kristian Rosenvold <kr...@gmail.com>.
This suggestion is much like what we came up with the last time
we discussed this - about 3 weeks ago.
This behaviour is simple to achieve without a single line
of change; the release plugin already asks for a SCM tag name
distinct from the version number. (we *could* add some kind
of support for an explicit convention, we could even add a scm-lookup
to auto-roll forward on subsequent takes).
Now I've been trying to think if there's a sensible convention
that could be established that would allow us to
simply *keep* the tag name of the accepted version
without re-pushing another tag after release (and, since the tag
name can be etched into the pom of the released artifact, there
should be no real reason for confusion).
I've been thinking about a *tagging* convention along the lines
of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2,
maven-xx-plugin-2.3.2#3..."
Effectively we would delete #1 and #2 and keep the #3 tag, since this
vote passed on take 3.
maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the
released 2.3.2 version.
This is mostly a policy change on tag naming, we could implement this
without a line
of code change. Since both svn and git essentially have flawed tag
handling it makes sense to do a change like this.
Kristian
2013/6/28 Ralph Goers <ra...@dslextreme.com>:
> Can you provide the steps required to get the release plugin to work this way?
>
> Ralph
>
> On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
>
>> Hello,
>>
>> this seems to be the most popular discussion, so another 2 cents:
>> - Today I read the man page of git-tag again.
>> - It states very clearly you should never reuse tags, because unlike is the
>> case with subversion, once a git tag is out in the wild (and pushing to
>> git-wip is the jungle here), everyone who has fetched the tag would have to
>> delete it *manually* from her copy, otherwise it will point to the wrong
>> hash eternally.
>>
>> Another approach:
>> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1, but
>> *not* to the version.
>> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
>> maven-foo-2.16 using the SCM directly.
>> - The version stays enduser friendly and the tag in the pom points to the
>> sources correctly.
>> - Diffing between different RCs and the final versions is easy.
>> - No one has to fiddle with invalid workspaces/clones.
>> - For the release manager it is just one additional SCM call.
>>
>> Regards Mirko
>> --
>> Sent from my mobile
>> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>>
>>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>>>> I do not believe that can be done with the release plugins as the pom
>>> has to specify the same version as the tag. If you then rename the tag you
>>> would have to modify the poms in the tag, which makes the release invalid.
>>>>
>>>> Have you ever used the release plugin? If not, I would suggest you try
>>> it and offer up patches to change it instead of carrying on this discussion
>>> as it is unlikely maven is going to stop using the release plugin.
>>>
>>> This is straying further off the original topic.
>>>
>>> Whether people use the release plugin or some other method is not
>>> really relevant to the release vote itself.
>>>
>>> All the process that leads up to the vote is merely a means to trying
>>> to ensure that the release candidate as as good as possible.
>>>
>>> What matters is the vote - the public declaration that the RC has been
>>> reviewed and approved.
>>> Only a PMC-approved vote can get the legal protection of the ASF.
>>>
>>> The vote needs to be performed on input that can be readily checked by
>>> any reviewer.
>>> The vote has to be seen to be open and complete.
>>> The SVN (or GIT) coordinate is an essential part of the input, as it
>>> is the only practical way to check provenance of the files in the
>>> archives.
>>>
>>> Given that part of the Maven philisophy is to ensure that all plugin
>>> versions must be specified to ensure repeatable builds, I'm a bit
>>> surprised how much resistance there is to providing the specific
>>> source which was used as input to the build process.
>>>
>>> The only change that this requires to be made to the process is to add
>>> the revision number and tag name [1] to the release vote e-mail.
>>> Is that really too much to ask?
>>>
>>> [1] A revision on its one is insufficient as the ASF uses a shared SVN
>>> repo; the location within the tree is needed to be able to select the
>>> revelant portion of the tree. The tag name is one such way to provide
>>> the information.
>>>
>>>> Ralph
>>>>
>>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>>>>> successful tag to the GA tag.
>>>>>
>>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>>> failed release vote instead of deleting them.
>>>>>>
>>>>>>
>>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>>>
>>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>>> ralph.goers@dslextreme.com>wrote:
>>>>>>>
>>>>>>>> Again I have to disagree. The release manager will send an email
>>> closing
>>>>>>>> the prior release. At this point all the prior release artifacts
>>> are junk
>>>>>>>> even if they still exist. At some point the release manager will
>>> delete
>>>>>>>> the tag and rerun the release
>>>>>>>
>>>>>>>
>>>>>>> That's a no-no IMO. Tags that have been voted on should never be
>>> deleted.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> At this point the tag is still junk to everyone else because they
>>> have no
>>>>>>>> idea what the RM is doing - so they shouldn't be making assumptions
>>> about
>>>>>>>> non-released tags. Once he sends the email though the tag will be
>>> valid.
>>>>>>>> Sure having the revision number helps but unless the RM completely
>>> screws
>>>>>>>> up the tag should be sufficient.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>>>
>>>>>>>>> Not really, no. The developer may have re-spun it again and be
>>> about to
>>>>>>>>> email again. You have no idea what you're looking at unless you
>>> know the
>>>>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>>>>> become
>>>>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>>>>> rather
>>>>>>>>> than wait until forced to.
>>>>>>>>>
>>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>>> ralph.goers@dslextreme.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I disagree that the revision is required. I know that the RM is
>>> going
>>>>>>>> to
>>>>>>>>>> recreate the tag with each release candidate. Therefore, so long
>>> as I
>>>>>>>>>> refetch that tag for every release vote I can be confident that I
>>> am
>>>>>>>>>> reviewing the release contents.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>>>
>>>>>>>>>>> The mission of the ASF is to release software as source, and to
>>> ensure
>>>>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>>>>
>>>>>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>>>>>> The review process needs to establish that the proposed source
>>> release
>>>>>>>>>>> meets those aims.
>>>>>>>>>>>
>>>>>>>>>>> It's all but impossible for reviewers to examine every single
>>> file in
>>>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>>>
>>>>>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
>>> and
>>>>>>>>>>> accepting new contributions.
>>>>>>>>>>> So provided that all the files in the source release are also
>>> present
>>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source release
>>> meets
>>>>>>>>>>> the ASF criteria.
>>>>>>>>>>>
>>>>>>>>>>> Without having the SCM as a database of validated files, there
>>> are far
>>>>>>>>>>> too many files in the average source archive to check
>>> individually.
>>>>>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>>>
>>>>>>>>>>> Therefore, I contend that a release vote does not make sense
>>> without
>>>>>>>>>>> the SCM tag.
>>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
>>> also
>>>>>>>>>>> needs the revision.
>>>>>>>>>>>
>>>>>>>>>>> Whether every reviewer actually checks the source archive against
>>> SCM
>>>>>>>>>>> is another matter.
>>>>>>>>>>> But if the required SCM information is not present, it would be
>>>>>>>>>>> difficult to argue that the RM had provided sufficient
>>> information for
>>>>>>>>>>> a valid review to take place.
>>>>>>>>>>>
>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition<
>>> http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Ralph Goers <ra...@dslextreme.com>.
Can you provide the steps required to get the release plugin to work this way?
Ralph
On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote:
> Hello,
>
> this seems to be the most popular discussion, so another 2 cents:
> - Today I read the man page of git-tag again.
> - It states very clearly you should never reuse tags, because unlike is the
> case with subversion, once a git tag is out in the wild (and pushing to
> git-wip is the jungle here), everyone who has fetched the tag would have to
> delete it *manually* from her copy, otherwise it will point to the wrong
> hash eternally.
>
> Another approach:
> - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1, but
> *not* to the version.
> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
> maven-foo-2.16 using the SCM directly.
> - The version stays enduser friendly and the tag in the pom points to the
> sources correctly.
> - Diffing between different RCs and the final versions is easy.
> - No one has to fiddle with invalid workspaces/clones.
> - For the release manager it is just one additional SCM call.
>
> Regards Mirko
> --
> Sent from my mobile
> On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
>
>> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
>>> I do not believe that can be done with the release plugins as the pom
>> has to specify the same version as the tag. If you then rename the tag you
>> would have to modify the poms in the tag, which makes the release invalid.
>>>
>>> Have you ever used the release plugin? If not, I would suggest you try
>> it and offer up patches to change it instead of carrying on this discussion
>> as it is unlikely maven is going to stop using the release plugin.
>>
>> This is straying further off the original topic.
>>
>> Whether people use the release plugin or some other method is not
>> really relevant to the release vote itself.
>>
>> All the process that leads up to the vote is merely a means to trying
>> to ensure that the release candidate as as good as possible.
>>
>> What matters is the vote - the public declaration that the RC has been
>> reviewed and approved.
>> Only a PMC-approved vote can get the legal protection of the ASF.
>>
>> The vote needs to be performed on input that can be readily checked by
>> any reviewer.
>> The vote has to be seen to be open and complete.
>> The SVN (or GIT) coordinate is an essential part of the input, as it
>> is the only practical way to check provenance of the files in the
>> archives.
>>
>> Given that part of the Maven philisophy is to ensure that all plugin
>> versions must be specified to ensure repeatable builds, I'm a bit
>> surprised how much resistance there is to providing the specific
>> source which was used as input to the build process.
>>
>> The only change that this requires to be made to the process is to add
>> the revision number and tag name [1] to the release vote e-mail.
>> Is that really too much to ask?
>>
>> [1] A revision on its one is insufficient as the ASF uses a shared SVN
>> repo; the location within the tree is needed to be able to select the
>> revelant portion of the tree. The tag name is one such way to provide
>> the information.
>>
>>> Ralph
>>>
>>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>>
>>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>>>> successful tag to the GA tag.
>>>>
>>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
>> failed release vote instead of deleting them.
>>>>>
>>>>>
>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>>
>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
>> ralph.goers@dslextreme.com>wrote:
>>>>>>
>>>>>>> Again I have to disagree. The release manager will send an email
>> closing
>>>>>>> the prior release. At this point all the prior release artifacts
>> are junk
>>>>>>> even if they still exist. At some point the release manager will
>> delete
>>>>>>> the tag and rerun the release
>>>>>>
>>>>>>
>>>>>> That's a no-no IMO. Tags that have been voted on should never be
>> deleted.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>>> At this point the tag is still junk to everyone else because they
>> have no
>>>>>>> idea what the RM is doing - so they shouldn't be making assumptions
>> about
>>>>>>> non-released tags. Once he sends the email though the tag will be
>> valid.
>>>>>>> Sure having the revision number helps but unless the RM completely
>> screws
>>>>>>> up the tag should be sufficient.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>
>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>>
>>>>>>>> Not really, no. The developer may have re-spun it again and be
>> about to
>>>>>>>> email again. You have no idea what you're looking at unless you
>> know the
>>>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>>>> become
>>>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>>>> rather
>>>>>>>> than wait until forced to.
>>>>>>>>
>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
>> ralph.goers@dslextreme.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I disagree that the revision is required. I know that the RM is
>> going
>>>>>>> to
>>>>>>>>> recreate the tag with each release candidate. Therefore, so long
>> as I
>>>>>>>>> refetch that tag for every release vote I can be confident that I
>> am
>>>>>>>>> reviewing the release contents.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>>
>>>>>>>>>> The mission of the ASF is to release software as source, and to
>> ensure
>>>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>>>
>>>>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>>>>> The review process needs to establish that the proposed source
>> release
>>>>>>>>>> meets those aims.
>>>>>>>>>>
>>>>>>>>>> It's all but impossible for reviewers to examine every single
>> file in
>>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>>
>>>>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
>> and
>>>>>>>>>> accepting new contributions.
>>>>>>>>>> So provided that all the files in the source release are also
>> present
>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source release
>> meets
>>>>>>>>>> the ASF criteria.
>>>>>>>>>>
>>>>>>>>>> Without having the SCM as a database of validated files, there
>> are far
>>>>>>>>>> too many files in the average source archive to check
>> individually.
>>>>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>>
>>>>>>>>>> Therefore, I contend that a release vote does not make sense
>> without
>>>>>>>>>> the SCM tag.
>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
>> also
>>>>>>>>>> needs the revision.
>>>>>>>>>>
>>>>>>>>>> Whether every reviewer actually checks the source archive against
>> SCM
>>>>>>>>>> is another matter.
>>>>>>>>>> But if the required SCM information is not present, it would be
>>>>>>>>>> difficult to argue that the RM had provided sufficient
>> information for
>>>>>>>>>> a valid review to take place.
>>>>>>>>>>
>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition<
>> http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Hello,
this seems to be the most popular discussion, so another 2 cents:
- Today I read the man page of git-tag again.
- It states very clearly you should never reuse tags, because unlike is the
case with subversion, once a git tag is out in the wild (and pushing to
git-wip is the jungle here), everyone who has fetched the tag would have to
delete it *manually* from her copy, otherwise it will point to the wrong
hash eternally.
Another approach:
- Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1, but
*not* to the version.
- *After* a successful vote create a copy of tag maven-foo-2.16rc1 as
maven-foo-2.16 using the SCM directly.
- The version stays enduser friendly and the tag in the pom points to the
sources correctly.
- Diffing between different RCs and the final versions is easy.
- No one has to fiddle with invalid workspaces/clones.
- For the release manager it is just one additional SCM call.
Regards Mirko
--
Sent from my mobile
On Jun 27, 2013 4:42 PM, "sebb" <se...@gmail.com> wrote:
> On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
> > I do not believe that can be done with the release plugins as the pom
> has to specify the same version as the tag. If you then rename the tag you
> would have to modify the poms in the tag, which makes the release invalid.
> >
> > Have you ever used the release plugin? If not, I would suggest you try
> it and offer up patches to change it instead of carrying on this discussion
> as it is unlikely maven is going to stop using the release plugin.
>
> This is straying further off the original topic.
>
> Whether people use the release plugin or some other method is not
> really relevant to the release vote itself.
>
> All the process that leads up to the vote is merely a means to trying
> to ensure that the release candidate as as good as possible.
>
> What matters is the vote - the public declaration that the RC has been
> reviewed and approved.
> Only a PMC-approved vote can get the legal protection of the ASF.
>
> The vote needs to be performed on input that can be readily checked by
> any reviewer.
> The vote has to be seen to be open and complete.
> The SVN (or GIT) coordinate is an essential part of the input, as it
> is the only practical way to check provenance of the files in the
> archives.
>
> Given that part of the Maven philisophy is to ensure that all plugin
> versions must be specified to ensure repeatable builds, I'm a bit
> surprised how much resistance there is to providing the specific
> source which was used as input to the build process.
>
> The only change that this requires to be made to the process is to add
> the revision number and tag name [1] to the release vote e-mail.
> Is that really too much to ask?
>
> [1] A revision on its one is insufficient as the ASF uses a shared SVN
> repo; the location within the tree is needed to be able to select the
> revelant portion of the tree. The tag name is one such way to provide
> the information.
>
> > Ralph
> >
> > On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
> >
> >> It would be a lot better to use RC1 RC2 etc initially, and copy the
> >> successful tag to the GA tag.
> >>
> >> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
> >>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a
> failed release vote instead of deleting them.
> >>>
> >>>
> >>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> >>>
> >>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <
> ralph.goers@dslextreme.com>wrote:
> >>>>
> >>>>> Again I have to disagree. The release manager will send an email
> closing
> >>>>> the prior release. At this point all the prior release artifacts
> are junk
> >>>>> even if they still exist. At some point the release manager will
> delete
> >>>>> the tag and rerun the release
> >>>>
> >>>>
> >>>> That's a no-no IMO. Tags that have been voted on should never be
> deleted.
> >>>>
> >>>> Gary
> >>>>
> >>>>
> >>>>
> >>>>> At this point the tag is still junk to everyone else because they
> have no
> >>>>> idea what the RM is doing - so they shouldn't be making assumptions
> about
> >>>>> non-released tags. Once he sends the email though the tag will be
> valid.
> >>>>> Sure having the revision number helps but unless the RM completely
> screws
> >>>>> up the tag should be sufficient.
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>
> >>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> >>>>>
> >>>>>> Not really, no. The developer may have re-spun it again and be
> about to
> >>>>>> email again. You have no idea what you're looking at unless you
> know the
> >>>>>> revision. SVN will die off within a decade and this discussion will
> >>>>> become
> >>>>>> critical. Better to figure out how to support proper techniques now,
> >>>>> rather
> >>>>>> than wait until forced to.
> >>>>>>
> >>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <
> ralph.goers@dslextreme.com
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I disagree that the revision is required. I know that the RM is
> going
> >>>>> to
> >>>>>>> recreate the tag with each release candidate. Therefore, so long
> as I
> >>>>>>> refetch that tag for every release vote I can be confident that I
> am
> >>>>>>> reviewing the release contents.
> >>>>>>>
> >>>>>>> Ralph
> >>>>>>>
> >>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >>>>>>>
> >>>>>>>> The mission of the ASF is to release software as source, and to
> ensure
> >>>>>>>> that the released source is available under the Apache Licence.
> >>>>>>>>
> >>>>>>>> Before a release can be approved it must be voted on by the PMC.
> >>>>>>>> The review process needs to establish that the proposed source
> release
> >>>>>>>> meets those aims.
> >>>>>>>>
> >>>>>>>> It's all but impossible for reviewers to examine every single
> file in
> >>>>>>>> a source archive to determine if it meets the criteria.
> >>>>>>>> And it's not unknown for spurious files to creep into a release
> >>>>>>>> (perhaps from a stale workspace - are releases always built from a
> >>>>>>>> fresh checkout of the tag?)
> >>>>>>>>
> >>>>>>>> However, PMCs are also required to check what is added to the SCM
> >>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
> >>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
> and
> >>>>>>>> accepting new contributions.
> >>>>>>>> So provided that all the files in the source release are also
> present
> >>>>>>>> in SCM, the PMC can be reasonably sure that the source release
> meets
> >>>>>>>> the ASF criteria.
> >>>>>>>>
> >>>>>>>> Without having the SCM as a database of validated files, there
> are far
> >>>>>>>> too many files in the average source archive to check
> individually.
> >>>>>>>> And how would one check their provenance? The obvious way is to
> >>>>>>>> compare them with the entries in SCM.
> >>>>>>>>
> >>>>>>>> Therefore, I contend that a release vote does not make sense
> without
> >>>>>>>> the SCM tag.
> >>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail
> also
> >>>>>>>> needs the revision.
> >>>>>>>>
> >>>>>>>> Whether every reviewer actually checks the source archive against
> SCM
> >>>>>>>> is another matter.
> >>>>>>>> But if the required SCM information is not present, it would be
> >>>>>>>> difficult to argue that the RM had provided sufficient
> information for
> >>>>>>>> a valid review to take place.
> >>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >>>> Spring Batch in Action <http://www.manning.com/templier/>
> >>>> Blog: http://garygregory.wordpress.com
> >>>> Home: http://garygregory.com/
> >>>> Tweet! http://twitter.com/GaryGregory
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by sebb <se...@gmail.com>.
On 27 June 2013 15:05, Ralph Goers <rg...@apache.org> wrote:
> I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid.
>
> Have you ever used the release plugin? If not, I would suggest you try it and offer up patches to change it instead of carrying on this discussion as it is unlikely maven is going to stop using the release plugin.
This is straying further off the original topic.
Whether people use the release plugin or some other method is not
really relevant to the release vote itself.
All the process that leads up to the vote is merely a means to trying
to ensure that the release candidate as as good as possible.
What matters is the vote - the public declaration that the RC has been
reviewed and approved.
Only a PMC-approved vote can get the legal protection of the ASF.
The vote needs to be performed on input that can be readily checked by
any reviewer.
The vote has to be seen to be open and complete.
The SVN (or GIT) coordinate is an essential part of the input, as it
is the only practical way to check provenance of the files in the
archives.
Given that part of the Maven philisophy is to ensure that all plugin
versions must be specified to ensure repeatable builds, I'm a bit
surprised how much resistance there is to providing the specific
source which was used as input to the build process.
The only change that this requires to be made to the process is to add
the revision number and tag name [1] to the release vote e-mail.
Is that really too much to ask?
[1] A revision on its one is insufficient as the ASF uses a shared SVN
repo; the location within the tree is needed to be able to select the
revelant portion of the tree. The tag name is one such way to provide
the information.
> Ralph
>
> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>
>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>> successful tag to the GA tag.
>>
>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them.
>>>
>>>
>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>
>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>>>
>>>>> Again I have to disagree. The release manager will send an email closing
>>>>> the prior release. At this point all the prior release artifacts are junk
>>>>> even if they still exist. At some point the release manager will delete
>>>>> the tag and rerun the release
>>>>
>>>>
>>>> That's a no-no IMO. Tags that have been voted on should never be deleted.
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>>> At this point the tag is still junk to everyone else because they have no
>>>>> idea what the RM is doing - so they shouldn't be making assumptions about
>>>>> non-released tags. Once he sends the email though the tag will be valid.
>>>>> Sure having the revision number helps but unless the RM completely screws
>>>>> up the tag should be sufficient.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>
>>>>>> Not really, no. The developer may have re-spun it again and be about to
>>>>>> email again. You have no idea what you're looking at unless you know the
>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>> become
>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>> rather
>>>>>> than wait until forced to.
>>>>>>
>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>>>> wrote:
>>>>>>
>>>>>>> I disagree that the revision is required. I know that the RM is going
>>>>> to
>>>>>>> recreate the tag with each release candidate. Therefore, so long as I
>>>>>>> refetch that tag for every release vote I can be confident that I am
>>>>>>> reviewing the release contents.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>
>>>>>>>> The mission of the ASF is to release software as source, and to ensure
>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>
>>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>>> The review process needs to establish that the proposed source release
>>>>>>>> meets those aims.
>>>>>>>>
>>>>>>>> It's all but impossible for reviewers to examine every single file in
>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>>> fresh checkout of the tag?)
>>>>>>>>
>>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>>>>>> accepting new contributions.
>>>>>>>> So provided that all the files in the source release are also present
>>>>>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>>>>>> the ASF criteria.
>>>>>>>>
>>>>>>>> Without having the SCM as a database of validated files, there are far
>>>>>>>> too many files in the average source archive to check individually.
>>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>>> compare them with the entries in SCM.
>>>>>>>>
>>>>>>>> Therefore, I contend that a release vote does not make sense without
>>>>>>>> the SCM tag.
>>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>>>>>> needs the revision.
>>>>>>>>
>>>>>>>> Whether every reviewer actually checks the source archive against SCM
>>>>>>>> is another matter.
>>>>>>>> But if the required SCM information is not present, it would be
>>>>>>>> difficult to argue that the RM had provided sufficient information for
>>>>>>>> a valid review to take place.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Simone Tripodi <si...@apache.org>.
On Thu, Jun 27, 2013 at 4:39 PM, Jason van Zyl <ja...@tesla.io> wrote:
> Agreed.
>
> Our tooling and policy is embodied in the release plugin. I am personally fine with any policy changes that are required, but would argue anything we have is grandfathered in because we've been doing it so long. If changes are required, my requirement is that I do nothing more than I currently do which is to use the release plugin. I agree with Ralph that your avenue of change is by altering the release plugin because this discussion isn't going to result in anything unless it results in changes to the release plugin.
+1
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
>
> On Jun 27, 2013, at 10:05 AM, Ralph Goers <rg...@apache.org> wrote:
>
>> I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid.
>>
>> Have you ever used the release plugin? If not, I would suggest you try it and offer up patches to change it instead of carrying on this discussion as it is unlikely maven is going to stop using the release plugin.
>>
>> Ralph
>>
>> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>>
>>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>>> successful tag to the GA tag.
>>>
>>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them.
>>>>
>>>>
>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>>
>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>>>>
>>>>>> Again I have to disagree. The release manager will send an email closing
>>>>>> the prior release. At this point all the prior release artifacts are junk
>>>>>> even if they still exist. At some point the release manager will delete
>>>>>> the tag and rerun the release
>>>>>
>>>>>
>>>>> That's a no-no IMO. Tags that have been voted on should never be deleted.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>>> At this point the tag is still junk to everyone else because they have no
>>>>>> idea what the RM is doing - so they shouldn't be making assumptions about
>>>>>> non-released tags. Once he sends the email though the tag will be valid.
>>>>>> Sure having the revision number helps but unless the RM completely screws
>>>>>> up the tag should be sufficient.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>>
>>>>>>> Not really, no. The developer may have re-spun it again and be about to
>>>>>>> email again. You have no idea what you're looking at unless you know the
>>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>>> become
>>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>>> rather
>>>>>>> than wait until forced to.
>>>>>>>
>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I disagree that the revision is required. I know that the RM is going
>>>>>> to
>>>>>>>> recreate the tag with each release candidate. Therefore, so long as I
>>>>>>>> refetch that tag for every release vote I can be confident that I am
>>>>>>>> reviewing the release contents.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>>
>>>>>>>>> The mission of the ASF is to release software as source, and to ensure
>>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>>
>>>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>>>> The review process needs to establish that the proposed source release
>>>>>>>>> meets those aims.
>>>>>>>>>
>>>>>>>>> It's all but impossible for reviewers to examine every single file in
>>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>>>> fresh checkout of the tag?)
>>>>>>>>>
>>>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>>>>>>> accepting new contributions.
>>>>>>>>> So provided that all the files in the source release are also present
>>>>>>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>>>>>>> the ASF criteria.
>>>>>>>>>
>>>>>>>>> Without having the SCM as a database of validated files, there are far
>>>>>>>>> too many files in the average source archive to check individually.
>>>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>>>> compare them with the entries in SCM.
>>>>>>>>>
>>>>>>>>> Therefore, I contend that a release vote does not make sense without
>>>>>>>>> the SCM tag.
>>>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>>>>>>> needs the revision.
>>>>>>>>>
>>>>>>>>> Whether every reviewer actually checks the source archive against SCM
>>>>>>>>> is another matter.
>>>>>>>>> But if the required SCM information is not present, it would be
>>>>>>>>> difficult to argue that the RM had provided sufficient information for
>>>>>>>>> a valid review to take place.
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Jason van Zyl <ja...@tesla.io>.
Agreed.
Our tooling and policy is embodied in the release plugin. I am personally fine with any policy changes that are required, but would argue anything we have is grandfathered in because we've been doing it so long. If changes are required, my requirement is that I do nothing more than I currently do which is to use the release plugin. I agree with Ralph that your avenue of change is by altering the release plugin because this discussion isn't going to result in anything unless it results in changes to the release plugin.
On Jun 27, 2013, at 10:05 AM, Ralph Goers <rg...@apache.org> wrote:
> I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid.
>
> Have you ever used the release plugin? If not, I would suggest you try it and offer up patches to change it instead of carrying on this discussion as it is unlikely maven is going to stop using the release plugin.
>
> Ralph
>
> On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
>
>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>> successful tag to the GA tag.
>>
>> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them.
>>>
>>>
>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>
>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>>>
>>>>> Again I have to disagree. The release manager will send an email closing
>>>>> the prior release. At this point all the prior release artifacts are junk
>>>>> even if they still exist. At some point the release manager will delete
>>>>> the tag and rerun the release
>>>>
>>>>
>>>> That's a no-no IMO. Tags that have been voted on should never be deleted.
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>>> At this point the tag is still junk to everyone else because they have no
>>>>> idea what the RM is doing - so they shouldn't be making assumptions about
>>>>> non-released tags. Once he sends the email though the tag will be valid.
>>>>> Sure having the revision number helps but unless the RM completely screws
>>>>> up the tag should be sufficient.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>
>>>>>> Not really, no. The developer may have re-spun it again and be about to
>>>>>> email again. You have no idea what you're looking at unless you know the
>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>> become
>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>> rather
>>>>>> than wait until forced to.
>>>>>>
>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>>>> wrote:
>>>>>>
>>>>>>> I disagree that the revision is required. I know that the RM is going
>>>>> to
>>>>>>> recreate the tag with each release candidate. Therefore, so long as I
>>>>>>> refetch that tag for every release vote I can be confident that I am
>>>>>>> reviewing the release contents.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>
>>>>>>>> The mission of the ASF is to release software as source, and to ensure
>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>
>>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>>> The review process needs to establish that the proposed source release
>>>>>>>> meets those aims.
>>>>>>>>
>>>>>>>> It's all but impossible for reviewers to examine every single file in
>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>>> fresh checkout of the tag?)
>>>>>>>>
>>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>>>>>> accepting new contributions.
>>>>>>>> So provided that all the files in the source release are also present
>>>>>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>>>>>> the ASF criteria.
>>>>>>>>
>>>>>>>> Without having the SCM as a database of validated files, there are far
>>>>>>>> too many files in the average source archive to check individually.
>>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>>> compare them with the entries in SCM.
>>>>>>>>
>>>>>>>> Therefore, I contend that a release vote does not make sense without
>>>>>>>> the SCM tag.
>>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>>>>>> needs the revision.
>>>>>>>>
>>>>>>>> Whether every reviewer actually checks the source archive against SCM
>>>>>>>> is another matter.
>>>>>>>> But if the required SCM information is not present, it would be
>>>>>>>> difficult to argue that the RM had provided sufficient information for
>>>>>>>> a valid review to take place.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Release process updates
Posted by Ralph Goers <rg...@apache.org>.
I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid.
Have you ever used the release plugin? If not, I would suggest you try it and offer up patches to change it instead of carrying on this discussion as it is unlikely maven is going to stop using the release plugin.
Ralph
On Jun 25, 2013, at 4:14 PM, sebb <se...@gmail.com> wrote:
> It would be a lot better to use RC1 RC2 etc initially, and copy the
> successful tag to the GA tag.
>
> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them.
>>
>>
>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>
>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>>
>>>> Again I have to disagree. The release manager will send an email closing
>>>> the prior release. At this point all the prior release artifacts are junk
>>>> even if they still exist. At some point the release manager will delete
>>>> the tag and rerun the release
>>>
>>>
>>> That's a no-no IMO. Tags that have been voted on should never be deleted.
>>>
>>> Gary
>>>
>>>
>>>
>>>> At this point the tag is still junk to everyone else because they have no
>>>> idea what the RM is doing - so they shouldn't be making assumptions about
>>>> non-released tags. Once he sends the email though the tag will be valid.
>>>> Sure having the revision number helps but unless the RM completely screws
>>>> up the tag should be sufficient.
>>>>
>>>> Ralph
>>>>
>>>>
>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>
>>>>> Not really, no. The developer may have re-spun it again and be about to
>>>>> email again. You have no idea what you're looking at unless you know the
>>>>> revision. SVN will die off within a decade and this discussion will
>>>> become
>>>>> critical. Better to figure out how to support proper techniques now,
>>>> rather
>>>>> than wait until forced to.
>>>>>
>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>>> wrote:
>>>>>
>>>>>> I disagree that the revision is required. I know that the RM is going
>>>> to
>>>>>> recreate the tag with each release candidate. Therefore, so long as I
>>>>>> refetch that tag for every release vote I can be confident that I am
>>>>>> reviewing the release contents.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>
>>>>>>> The mission of the ASF is to release software as source, and to ensure
>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>
>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>> The review process needs to establish that the proposed source release
>>>>>>> meets those aims.
>>>>>>>
>>>>>>> It's all but impossible for reviewers to examine every single file in
>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>> fresh checkout of the tag?)
>>>>>>>
>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>>>>> accepting new contributions.
>>>>>>> So provided that all the files in the source release are also present
>>>>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>>>>> the ASF criteria.
>>>>>>>
>>>>>>> Without having the SCM as a database of validated files, there are far
>>>>>>> too many files in the average source archive to check individually.
>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>> compare them with the entries in SCM.
>>>>>>>
>>>>>>> Therefore, I contend that a release vote does not make sense without
>>>>>>> the SCM tag.
>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>>>>> needs the revision.
>>>>>>>
>>>>>>> Whether every reviewer actually checks the source archive against SCM
>>>>>>> is another matter.
>>>>>>> But if the required SCM information is not present, it would be
>>>>>>> difficult to argue that the RM had provided sufficient information for
>>>>>>> a valid review to take place.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Olivier Lamy <ol...@apache.org>.
2013/6/26 sebb <se...@gmail.com>:
> It would be a lot better to use RC1 RC2 etc initially, and copy the
> successful tag to the GA tag.
>
this mean modifying manually the pom to change version (from 1.0-RC1
to 1.0) before copying teh RC tag, changing the scm information etc...
Rebuild jars ? because if you change the pom it means you change the
sources so need an other build/vote..
Frankly currently we have a very simple process which works very fine:
* mvn clean release:prepare release:perform -B (-Dusername= -Dpassword=)
* verifying staging repo
* closing the staging repo
* cd target/checkout && mvn clean site-deploy
* and that's it
Perso, I don't want we move to something over complicated without any
real added value.
> On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them.
>>
>>
>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>
>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>>
>>>> Again I have to disagree. The release manager will send an email closing
>>>> the prior release. At this point all the prior release artifacts are junk
>>>> even if they still exist. At some point the release manager will delete
>>>> the tag and rerun the release.
>>>
>>>
>>> That's a no-no IMO. Tags that have been voted on should never be deleted.
>>>
>>> Gary
>>>
>>>
>>>
>>>> At this point the tag is still junk to everyone else because they have no
>>>> idea what the RM is doing - so they shouldn't be making assumptions about
>>>> non-released tags. Once he sends the email though the tag will be valid.
>>>> Sure having the revision number helps but unless the RM completely screws
>>>> up the tag should be sufficient.
>>>>
>>>> Ralph
>>>>
>>>>
>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>
>>>>> Not really, no. The developer may have re-spun it again and be about to
>>>>> email again. You have no idea what you're looking at unless you know the
>>>>> revision. SVN will die off within a decade and this discussion will
>>>> become
>>>>> critical. Better to figure out how to support proper techniques now,
>>>> rather
>>>>> than wait until forced to.
>>>>>
>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>>> wrote:
>>>>>
>>>>>> I disagree that the revision is required. I know that the RM is going
>>>> to
>>>>>> recreate the tag with each release candidate. Therefore, so long as I
>>>>>> refetch that tag for every release vote I can be confident that I am
>>>>>> reviewing the release contents.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>
>>>>>>> The mission of the ASF is to release software as source, and to ensure
>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>
>>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>>> The review process needs to establish that the proposed source release
>>>>>>> meets those aims.
>>>>>>>
>>>>>>> It's all but impossible for reviewers to examine every single file in
>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>>> fresh checkout of the tag?)
>>>>>>>
>>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>>>>> accepting new contributions.
>>>>>>> So provided that all the files in the source release are also present
>>>>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>>>>> the ASF criteria.
>>>>>>>
>>>>>>> Without having the SCM as a database of validated files, there are far
>>>>>>> too many files in the average source archive to check individually.
>>>>>>> And how would one check their provenance? The obvious way is to
>>>>>>> compare them with the entries in SCM.
>>>>>>>
>>>>>>> Therefore, I contend that a release vote does not make sense without
>>>>>>> the SCM tag.
>>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>>>>> needs the revision.
>>>>>>>
>>>>>>> Whether every reviewer actually checks the source archive against SCM
>>>>>>> is another matter.
>>>>>>> But if the required SCM information is not present, it would be
>>>>>>> difficult to argue that the RM had provided sufficient information for
>>>>>>> a valid review to take place.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by sebb <se...@gmail.com>.
It would be a lot better to use RC1 RC2 etc initially, and copy the
successful tag to the GA tag.
On 25 June 2013 19:38, Ralph Goers <ra...@dslextreme.com> wrote:
> Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them.
>
>
> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>
>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>
>>> Again I have to disagree. The release manager will send an email closing
>>> the prior release. At this point all the prior release artifacts are junk
>>> even if they still exist. At some point the release manager will delete
>>> the tag and rerun the release.
>>
>>
>> That's a no-no IMO. Tags that have been voted on should never be deleted.
>>
>> Gary
>>
>>
>>
>>> At this point the tag is still junk to everyone else because they have no
>>> idea what the RM is doing - so they shouldn't be making assumptions about
>>> non-released tags. Once he sends the email though the tag will be valid.
>>> Sure having the revision number helps but unless the RM completely screws
>>> up the tag should be sufficient.
>>>
>>> Ralph
>>>
>>>
>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>
>>>> Not really, no. The developer may have re-spun it again and be about to
>>>> email again. You have no idea what you're looking at unless you know the
>>>> revision. SVN will die off within a decade and this discussion will
>>> become
>>>> critical. Better to figure out how to support proper techniques now,
>>> rather
>>>> than wait until forced to.
>>>>
>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>> wrote:
>>>>
>>>>> I disagree that the revision is required. I know that the RM is going
>>> to
>>>>> recreate the tag with each release candidate. Therefore, so long as I
>>>>> refetch that tag for every release vote I can be confident that I am
>>>>> reviewing the release contents.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>
>>>>>> The mission of the ASF is to release software as source, and to ensure
>>>>>> that the released source is available under the Apache Licence.
>>>>>>
>>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>>> The review process needs to establish that the proposed source release
>>>>>> meets those aims.
>>>>>>
>>>>>> It's all but impossible for reviewers to examine every single file in
>>>>>> a source archive to determine if it meets the criteria.
>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>>> fresh checkout of the tag?)
>>>>>>
>>>>>> However, PMCs are also required to check what is added to the SCM
>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>>>> accepting new contributions.
>>>>>> So provided that all the files in the source release are also present
>>>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>>>> the ASF criteria.
>>>>>>
>>>>>> Without having the SCM as a database of validated files, there are far
>>>>>> too many files in the average source archive to check individually.
>>>>>> And how would one check their provenance? The obvious way is to
>>>>>> compare them with the entries in SCM.
>>>>>>
>>>>>> Therefore, I contend that a release vote does not make sense without
>>>>>> the SCM tag.
>>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>>>> needs the revision.
>>>>>>
>>>>>> Whether every reviewer actually checks the source archive against SCM
>>>>>> is another matter.
>>>>>> But if the required SCM information is not present, it would be
>>>>>> difficult to argue that the RM had provided sufficient information for
>>>>>> a valid review to take place.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Ralph Goers <ra...@dslextreme.com>.
Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them.
On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> Again I have to disagree. The release manager will send an email closing
>> the prior release. At this point all the prior release artifacts are junk
>> even if they still exist. At some point the release manager will delete
>> the tag and rerun the release.
>
>
> That's a no-no IMO. Tags that have been voted on should never be deleted.
>
> Gary
>
>
>
>> At this point the tag is still junk to everyone else because they have no
>> idea what the RM is doing - so they shouldn't be making assumptions about
>> non-released tags. Once he sends the email though the tag will be valid.
>> Sure having the revision number helps but unless the RM completely screws
>> up the tag should be sufficient.
>>
>> Ralph
>>
>>
>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>
>>> Not really, no. The developer may have re-spun it again and be about to
>>> email again. You have no idea what you're looking at unless you know the
>>> revision. SVN will die off within a decade and this discussion will
>> become
>>> critical. Better to figure out how to support proper techniques now,
>> rather
>>> than wait until forced to.
>>>
>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>> wrote:
>>>
>>>> I disagree that the revision is required. I know that the RM is going
>> to
>>>> recreate the tag with each release candidate. Therefore, so long as I
>>>> refetch that tag for every release vote I can be confident that I am
>>>> reviewing the release contents.
>>>>
>>>> Ralph
>>>>
>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>
>>>>> The mission of the ASF is to release software as source, and to ensure
>>>>> that the released source is available under the Apache Licence.
>>>>>
>>>>> Before a release can be approved it must be voted on by the PMC.
>>>>> The review process needs to establish that the proposed source release
>>>>> meets those aims.
>>>>>
>>>>> It's all but impossible for reviewers to examine every single file in
>>>>> a source archive to determine if it meets the criteria.
>>>>> And it's not unknown for spurious files to creep into a release
>>>>> (perhaps from a stale workspace - are releases always built from a
>>>>> fresh checkout of the tag?)
>>>>>
>>>>> However, PMCs are also required to check what is added to the SCM
>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>> This is done on an ongoing basis as part of reviewing check-ins and
>>>>> accepting new contributions.
>>>>> So provided that all the files in the source release are also present
>>>>> in SCM, the PMC can be reasonably sure that the source release meets
>>>>> the ASF criteria.
>>>>>
>>>>> Without having the SCM as a database of validated files, there are far
>>>>> too many files in the average source archive to check individually.
>>>>> And how would one check their provenance? The obvious way is to
>>>>> compare them with the entries in SCM.
>>>>>
>>>>> Therefore, I contend that a release vote does not make sense without
>>>>> the SCM tag.
>>>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>>>> needs the revision.
>>>>>
>>>>> Whether every reviewer actually checks the source archive against SCM
>>>>> is another matter.
>>>>> But if the required SCM information is not present, it would be
>>>>> difficult to argue that the RM had provided sufficient information for
>>>>> a valid review to take place.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> Again I have to disagree. The release manager will send an email closing
> the prior release. At this point all the prior release artifacts are junk
> even if they still exist. At some point the release manager will delete
> the tag and rerun the release.
That's a no-no IMO. Tags that have been voted on should never be deleted.
Gary
> At this point the tag is still junk to everyone else because they have no
> idea what the RM is doing - so they shouldn't be making assumptions about
> non-released tags. Once he sends the email though the tag will be valid.
> Sure having the revision number helps but unless the RM completely screws
> up the tag should be sufficient.
>
> Ralph
>
>
> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>
> > Not really, no. The developer may have re-spun it again and be about to
> > email again. You have no idea what you're looking at unless you know the
> > revision. SVN will die off within a decade and this discussion will
> become
> > critical. Better to figure out how to support proper techniques now,
> rather
> > than wait until forced to.
> >
> > On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
> >wrote:
> >
> >> I disagree that the revision is required. I know that the RM is going
> to
> >> recreate the tag with each release candidate. Therefore, so long as I
> >> refetch that tag for every release vote I can be confident that I am
> >> reviewing the release contents.
> >>
> >> Ralph
> >>
> >> On Jun 25, 2013, at 9:52 AM, sebb wrote:
> >>
> >>> The mission of the ASF is to release software as source, and to ensure
> >>> that the released source is available under the Apache Licence.
> >>>
> >>> Before a release can be approved it must be voted on by the PMC.
> >>> The review process needs to establish that the proposed source release
> >>> meets those aims.
> >>>
> >>> It's all but impossible for reviewers to examine every single file in
> >>> a source archive to determine if it meets the criteria.
> >>> And it's not unknown for spurious files to creep into a release
> >>> (perhaps from a stale workspace - are releases always built from a
> >>> fresh checkout of the tag?)
> >>>
> >>> However, PMCs are also required to check what is added to the SCM
> >>> (SVN/Git) to make sure it meets the required license criteria.
> >>> This is done on an ongoing basis as part of reviewing check-ins and
> >>> accepting new contributions.
> >>> So provided that all the files in the source release are also present
> >>> in SCM, the PMC can be reasonably sure that the source release meets
> >>> the ASF criteria.
> >>>
> >>> Without having the SCM as a database of validated files, there are far
> >>> too many files in the average source archive to check individually.
> >>> And how would one check their provenance? The obvious way is to
> >>> compare them with the entries in SCM.
> >>>
> >>> Therefore, I contend that a release vote does not make sense without
> >>> the SCM tag.
> >>> In the case of SVN, since tags are not immutable, the vote e-mail also
> >>> needs the revision.
> >>>
> >>> Whether every reviewer actually checks the source archive against SCM
> >>> is another matter.
> >>> But if the required SCM information is not present, it would be
> >>> difficult to argue that the RM had provided sufficient information for
> >>> a valid review to take place.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Release process updates
Posted by Ralph Goers <ra...@dslextreme.com>.
Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient.
Ralph
On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
> Not really, no. The developer may have re-spun it again and be about to
> email again. You have no idea what you're looking at unless you know the
> revision. SVN will die off within a decade and this discussion will become
> critical. Better to figure out how to support proper techniques now, rather
> than wait until forced to.
>
> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> I disagree that the revision is required. I know that the RM is going to
>> recreate the tag with each release candidate. Therefore, so long as I
>> refetch that tag for every release vote I can be confident that I am
>> reviewing the release contents.
>>
>> Ralph
>>
>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>
>>> The mission of the ASF is to release software as source, and to ensure
>>> that the released source is available under the Apache Licence.
>>>
>>> Before a release can be approved it must be voted on by the PMC.
>>> The review process needs to establish that the proposed source release
>>> meets those aims.
>>>
>>> It's all but impossible for reviewers to examine every single file in
>>> a source archive to determine if it meets the criteria.
>>> And it's not unknown for spurious files to creep into a release
>>> (perhaps from a stale workspace - are releases always built from a
>>> fresh checkout of the tag?)
>>>
>>> However, PMCs are also required to check what is added to the SCM
>>> (SVN/Git) to make sure it meets the required license criteria.
>>> This is done on an ongoing basis as part of reviewing check-ins and
>>> accepting new contributions.
>>> So provided that all the files in the source release are also present
>>> in SCM, the PMC can be reasonably sure that the source release meets
>>> the ASF criteria.
>>>
>>> Without having the SCM as a database of validated files, there are far
>>> too many files in the average source archive to check individually.
>>> And how would one check their provenance? The obvious way is to
>>> compare them with the entries in SCM.
>>>
>>> Therefore, I contend that a release vote does not make sense without
>>> the SCM tag.
>>> In the case of SVN, since tags are not immutable, the vote e-mail also
>>> needs the revision.
>>>
>>> Whether every reviewer actually checks the source archive against SCM
>>> is another matter.
>>> But if the required SCM information is not present, it would be
>>> difficult to argue that the RM had provided sufficient information for
>>> a valid review to take place.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release process updates
Posted by Fred Cooke <fr...@gmail.com>.
Not really, no. The developer may have re-spun it again and be about to
email again. You have no idea what you're looking at unless you know the
revision. SVN will die off within a decade and this discussion will become
critical. Better to figure out how to support proper techniques now, rather
than wait until forced to.
On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> I disagree that the revision is required. I know that the RM is going to
> recreate the tag with each release candidate. Therefore, so long as I
> refetch that tag for every release vote I can be confident that I am
> reviewing the release contents.
>
> Ralph
>
> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>
> > The mission of the ASF is to release software as source, and to ensure
> > that the released source is available under the Apache Licence.
> >
> > Before a release can be approved it must be voted on by the PMC.
> > The review process needs to establish that the proposed source release
> > meets those aims.
> >
> > It's all but impossible for reviewers to examine every single file in
> > a source archive to determine if it meets the criteria.
> > And it's not unknown for spurious files to creep into a release
> > (perhaps from a stale workspace - are releases always built from a
> > fresh checkout of the tag?)
> >
> > However, PMCs are also required to check what is added to the SCM
> > (SVN/Git) to make sure it meets the required license criteria.
> > This is done on an ongoing basis as part of reviewing check-ins and
> > accepting new contributions.
> > So provided that all the files in the source release are also present
> > in SCM, the PMC can be reasonably sure that the source release meets
> > the ASF criteria.
> >
> > Without having the SCM as a database of validated files, there are far
> > too many files in the average source archive to check individually.
> > And how would one check their provenance? The obvious way is to
> > compare them with the entries in SCM.
> >
> > Therefore, I contend that a release vote does not make sense without
> > the SCM tag.
> > In the case of SVN, since tags are not immutable, the vote e-mail also
> > needs the revision.
> >
> > Whether every reviewer actually checks the source archive against SCM
> > is another matter.
> > But if the required SCM information is not present, it would be
> > difficult to argue that the RM had provided sufficient information for
> > a valid review to take place.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release process updates
Posted by Gary Gregory <ga...@gmail.com>.
For record keeping purposes, the SVN revision + tag combo is better because
some RM's have inadvertently reused RC tags in the past. As Sebb pointed
out tags are mutable.
Gary
On Tue, Jun 25, 2013 at 1:52 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> I disagree that the revision is required. I know that the RM is going to
> recreate the tag with each release candidate. Therefore, so long as I
> refetch that tag for every release vote I can be confident that I am
> reviewing the release contents.
>
> Ralph
>
> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>
> > The mission of the ASF is to release software as source, and to ensure
> > that the released source is available under the Apache Licence.
> >
> > Before a release can be approved it must be voted on by the PMC.
> > The review process needs to establish that the proposed source release
> > meets those aims.
> >
> > It's all but impossible for reviewers to examine every single file in
> > a source archive to determine if it meets the criteria.
> > And it's not unknown for spurious files to creep into a release
> > (perhaps from a stale workspace - are releases always built from a
> > fresh checkout of the tag?)
> >
> > However, PMCs are also required to check what is added to the SCM
> > (SVN/Git) to make sure it meets the required license criteria.
> > This is done on an ongoing basis as part of reviewing check-ins and
> > accepting new contributions.
> > So provided that all the files in the source release are also present
> > in SCM, the PMC can be reasonably sure that the source release meets
> > the ASF criteria.
> >
> > Without having the SCM as a database of validated files, there are far
> > too many files in the average source archive to check individually.
> > And how would one check their provenance? The obvious way is to
> > compare them with the entries in SCM.
> >
> > Therefore, I contend that a release vote does not make sense without
> > the SCM tag.
> > In the case of SVN, since tags are not immutable, the vote e-mail also
> > needs the revision.
> >
> > Whether every reviewer actually checks the source archive against SCM
> > is another matter.
> > But if the required SCM information is not present, it would be
> > difficult to argue that the RM had provided sufficient information for
> > a valid review to take place.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Release process updates
Posted by Ralph Goers <ra...@dslextreme.com>.
I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents.
Ralph
On Jun 25, 2013, at 9:52 AM, sebb wrote:
> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
> And it's not unknown for spurious files to creep into a release
> (perhaps from a stale workspace - are releases always built from a
> fresh checkout of the tag?)
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> the SCM tag.
> In the case of SVN, since tags are not immutable, the vote e-mail also
> needs the revision.
>
> Whether every reviewer actually checks the source archive against SCM
> is another matter.
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a valid review to take place.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org