On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com wrote:
Reminder: all this thread is just about is adding the following lines
to vote e-mails:
SVN Tag:
https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
2013/6/26 sebb seb...@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
On 1 July 2013 08:17, Andreas Gudian andreas.gud...@gmail.com wrote:
2013/6/26 sebb seb...@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
On 1 July 2013 07:18, Chris Graham chrisgw...@gmail.com wrote:
On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com wrote:
Reminder: all this thread is just about is adding the following lines
to vote e-mails:
SVN Tag:
On 1 July 2013 07:18, Chris Graham chrisgw...@gmail.com wrote:
On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com wrote:
Reminder: all this thread is just about is adding the following lines
to vote e-mails:
SVN Tag:
On 30 June 2013 23:33, sebb seb...@gmail.com wrote:
On 30 June 2013 19:20, sebb seb...@gmail.com wrote:
snip/
Reminder: all this thread is just about is adding the following lines
to vote e-mails:
SVN Tag:
https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
On Mon, Jul 1, 2013 at 7:14 PM, sebb seb...@gmail.com wrote:
On 1 July 2013 07:18, Chris Graham chrisgw...@gmail.com wrote:
On Mon, Jul 1, 2013 at 4:20 AM, sebb seb...@gmail.com wrote:
Reminder: all this thread is just about is adding the following lines
to vote e-mails:
SVN Tag:
So, if everyone here likes this idea, by all means let's do that. On the
other hand, if there is no consensus here, I wish that the Foundation
had a
clearer venue for discussing global policies like this.
I hope I don't have to argue that it is ASF policy to only release
source files
+1 - I agree with Chris.
Besides, if something DOES change in the svn/git tag, we get an email
notification so we can immediately figure out what's going on. In addition,
if you compare what you are voting on to whatever is the latest version of the
the tag, if there is any difference
Deleting and recreating a Git tag once published is an *extremely* stupid
thing to do, at least an order of magnitude more so than the same action in
SVN. I sincerely hope that developers in this community would not engage
in such activities.
Nevertheless, this thread isn't about that, it's
Guys, even if not convinced this is really useful,
I suppose voting template could just be adjusted so that the sha1
or svn revision be added in the VOTE thread, and then get back to code as
usual?
As it is just a 5 seconds additional operation to be done by the RM, I
think this is acceptable if
On Monday, 1 July 2013, Baptiste MATHUS wrote:
Guys, even if not convinced this is really useful,
I suppose voting template could just be adjusted so that the sha1
or svn revision be added in the VOTE thread, and then get back to code as
usual?
+1
As it is just a 5 seconds additional
For Git the only thing that is needed is the unique 40 character hash such
as this:
FreeAir:youtube-dl fred$ git rev-parse HEAD
48bfb5f2387ab47e1973d9db0782a9af66ffc4e6
It's just sloppy not to do this; if a quality release process is required,
so is the SVN rev number. If good enough is OK, then
Fine with me. Thanks for the explanation sebb.
Gary
On Jun 30, 2013, at 14:20, sebb seb...@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
On 30 June 2013 19:48, Fred Cooke fred.co...@gmail.com wrote:
For Git the only thing that is needed is the unique 40 character hash such
as this:
FreeAir:youtube-dl fred$ git rev-parse HEAD
48bfb5f2387ab47e1973d9db0782a9af66ffc4e6
OK, so what is the Git command to download a copy of the
OK, so what is the Git command to download a copy of the sources that
are part of the hash?
git checkout hash
Then observe the tree. You can also export an archive, though I don't
recall the exact command off the top of my hand.
Don't I need to know something about the Git repo it comes
On the one hand, I think that, in many Apache communities, comparing the
source release to the VCS is the exception and not the rule, and may never
have happened, even once. (I think that there is at least an even chance
that some crusty veteran of httpd will arrive in this thread and call me
out
On 30 June 2013 19:20, sebb seb...@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
On 30 June 2013 23:32, Benson Margulies bimargul...@gmail.com wrote:
On the one hand, I think that, in many Apache communities, comparing the
source release to the VCS is the exception and not the rule, and may never
have happened, even once. (I think that there is at least an even chance
that
2013/6/26 sebb seb...@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
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
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
+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.rosenv...@gmail.com wrote:
This suggestion is much like what we came up with the last
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
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
On Fri, Jun 28, 2013 at 8:35 PM, sebb seb...@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
On Fri, Jun 28, 2013 at 9:04 PM, Fred Cooke fred.co...@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
On Jun 28, 2013, at 7:05, Fred Cooke fred.co...@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
@ 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
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
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.
2013/6/28 Fred Cooke fred.co...@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
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]
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
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
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
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
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
kristian.rosenv...@gmail.com:
Yup, or the prepare goal actually has some kind of auto suggest
tagname option; which involves
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
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
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
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
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),
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
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
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
On Wed, Jun 26, 2013 at 7:06 PM, sebb seb...@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
On 26 June 2013 02:59, Barrie Treloar baerr...@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
On 26 June 2013 10:56, Chris Graham chrisgw...@gmail.com wrote:
On Wed, Jun 26, 2013 at 7:06 PM, sebb seb...@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
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
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 mfriedenha...@gmail.com:
Hello there,
when. respinning
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
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:
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
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 ralph.go...@dslextreme.comwrote:
I disagree that the revision is
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
On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote:
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
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
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.comwrote:
Again I have to disagree. The release manager
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
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 u...@thetaphi.de wrote:
Hi,
I agree with sebb. I am not a Maven committer, but the release revision is
very important in the Lucene
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é
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 herve.bout...@free.frwrote:
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
On 25 June 2013 19:19, 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
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,
On 25 June 2013 19:33, Hervé BOUTEMY herve.bout...@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
2013/6/26 sebb seb...@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
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 seb...@gmail.com wrote:
The mission of the ASF is to release software as source, and to ensure
that the
On Tue, Jun 25, 2013 at 7: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.
+1 ! :)
Gary
On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote:
Yeah - I agree with this. I rename them to
-1
Except then the poms will point to the wrong place.
On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory garydgreg...@gmail.comwrote:
On Tue, Jun 25, 2013 at 7: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
On 26 June 2013 01:04, Chris Graham chrisgw...@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 garydgreg...@gmail.comwrote:
On Tue, Jun 25, 2013 at 7:14 PM, sebb seb...@gmail.com
On 26 June 2013 00:34, Chris Graham chrisgw...@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 seb...@gmail.com wrote:
The mission
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
On 26 June 2013 01:25, Barrie Treloar baerr...@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
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 seb...@gmail.com wrote:
On 26 June 2013 00:34, Chris Graham chrisgw...@gmail.com
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 baerr...@gmail.com:
And if the mvn deploy fails for any reason?
We get this often enough with a crappy
On 25 June 2013 20:15, Uwe Schindler u...@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
On Wed, Jun 26, 2013 at 10:36 AM, sebb seb...@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?
On 26 June 2013 01:43, Chris Graham chrisgw...@gmail.com wrote:
On Wed, Jun 26, 2013 at 10:36 AM, sebb seb...@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?
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.
On 26 June 2013 10:19, sebb seb...@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
On 26 June 2013 02:18, Barrie Treloar baerr...@gmail.com wrote:
On 26 June 2013 10:19, sebb seb...@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
*
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
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 chrisgw...@gmail.com wrote:
-1
Except then the poms will point to the wrong place.
Depends how the poms are updated.
On
+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]
85 matches
Mail list logo
