maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Release process updates
Date Fri, 28 Jun 2013 05:27:44 GMT
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" <sebbaz@gmail.com> wrote:
> 
>> On 27 June 2013 15:05, Ralph Goers <rgoers@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 <sebbaz@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 <ralph.goers@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


Mime
View raw message