On 27 June 2013 15:05, Ralph Goers <rgo...@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 <seb...@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.go...@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.go...@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.go...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
