All nice ideas, but let's go back to a real usecase:
Let's assume we're having an issue with componentX-1.4
If you weren't one of the testers, then this dependency was pulled from
Maven Central. You can check out the code as specified in the tag, etc.
etc. No issues here.
But if you were one
Now the issue with componentX-1.4 that you wan to test is one that only
shows up behind your corporate proxy, and you have a system set up with the
failing case and you dare not change anything...
So you add the staging repo to your mirror, run the test case, and drop the
test artifact from the
Although it is slightly off-topic (I assumed our Apache environment), but
also in this case: as long as componentX-1.4 was staged and not released,
developers must adjust their settings.xml to test componentX-1.4.
So they should be aware that this component was not released and should
remove
If you add apache staging to your corp proxy
and expose that to everyone you are mixing test and production.
/me dislikes the concept.
The way I usually solve this is to have an additional
corp repo-url that exposes the regular internal repo
*and* staging. This url is used to test staging.
(I
On Monday, 3 June 2013, Kristian Rosenvold wrote:
If you add apache staging to your corp proxy
and expose that to everyone you are mixing test and production.
/me dislikes the concept.
The way I usually solve this is to have an additional
corp repo-url that exposes the regular internal repo
Write this scenario up in the trouble shooting notes on how to test
staging releases.
I fit into the behind corporate proxy category but I have not had
this problem (I use Kristian's solution).
Admittedly the effort required to configure the corporate proxy for a
staging url is often enough to
Um, did I miss something, but what is a unreleased (ie for it to be pulled,
then it has to be right?) artifact doing in central to start with?
-Chris
On Tue, Jun 4, 2013 at 3:32 AM, Robert Scholte rfscho...@apache.org wrote:
All nice ideas, but let's go back to a real usecase:
Let's assume
-1 (binding)
Ralph
On May 29, 2013, at 3:01 AM, Stephen Connolly wrote:
We have been using a policy of only making releases without skipping
version numbers, e.g.
3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
Whereby if there is something wrong with the artifacts staged for release,
we
-1 binding to changing to burning versions.
On Sun, Jun 2, 2013 at 10:56 AM, Ralph Goers ralph.go...@dslextreme.com wrote:
-1 (binding)
Ralph
On May 29, 2013, at 3:01 AM, Stephen Connolly wrote:
We have been using a policy of only making releases without skipping
version numbers, e.g.
-1 non-binding, this is confusing. That's what RC tags are for.
Gary
On Jun 2, 2013, at 11:54, Benson Margulies bimargul...@gmail.com wrote:
-1 binding to changing to burning versions.
On Sun, Jun 2, 2013 at 10:56 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:
-1 (binding)
Ralph
On
from my experience, even if this question is not absolutely scm-specific,
git
brings us a new problem we didn't have with svn: once a tag is set on the
canonical repo and replicated on developers' repos, it is not automatically
updated if updated in the canonical
Git brings you no such
On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke fred.co...@gmail.com wrote:
from my experience, even if this question is not absolutely scm-specific,
git
brings us a new problem we didn't have with svn: once a tag is set on the
canonical repo and replicated on developers' repos, it is not
Benson, read the rules:
http://httpd.apache.org/dev/voting.html
*-1 *No, I *veto* this action.
+1 + -1 != 0
On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies bimargul...@gmail.comwrote:
On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke fred.co...@gmail.com wrote:
from my experience, even if this
That link is for HTTPd.
For Apache general guidelines, read
http://www.apache.org/foundation/voting.html
-1 are only vetos for code modification, not procedural issues .
Cheers
2013/6/2 Fred Cooke fred.co...@gmail.com
Benson, read the rules:
http://httpd.apache.org/dev/voting.html
*-1
1. That page says 'obsolete' all over the top of it.
2. I can find you 27 email messages from board members and other
crusty veterans to the contrary.
Quoting from the replacement page:
-1 No. On issues where consensus is required, this vote counts as a
veto. All vetos must include an
Thanks, Baptiste, that's the reference I was looking for.
On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS bmat...@batmat.net wrote:
That link is for HTTPd.
For Apache general guidelines, read
http://www.apache.org/foundation/voting.html
-1 are only vetos for code modification, not procedural
I apologise. I had three tabs open from Apache, and grabbed the wrong one.
According to the correct, page, though:
-0.9: 'I *really* don't like this, but *I'm not going to stand in the
way*if everyone else wants to go ahead with it.'
There's an *implication* there that an extra -0.1 might
I will point out that for this specific vote I listed three options and a
criteria. So this vote has no vetoes. Simple sum of all binding votes
defines the result. If the sum is -3 then that says majority dont want to
burn version numbers. If the sum +3 then that says the majority want to
keep
I think it's time to step back a little. This whole vote was started
without any proper initial discussion, so to the extent there will be
any majority for a policy change, this will not be the vote where this
happens. But these votes tend to be great kickstarters for good
discussions, so instead
I would consider it delux if the release plugin were enhanced to
support a more sophisticated mapping between artifact versions and
tags -- as per Kristian, wouldn't it be cool if it could iterate over
tags while repeating itself on customer-visible release numbers? I'd
help to code this is we had
Fred,
We are talking more process here. Not the specifics of an individual SCM,
not everything is in git. We are still talking about the abstraction api
that the maven-scm handlers provide, of which git is but one.
-Chris
On Mon, Jun 3, 2013 at 4:42 AM, Fred Cooke fred.co...@gmail.com wrote:
Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
came to the conclusion that I thought this was anything to do with Git.
Subversion tags, though mutable, should not EVER be committed against or in
any other way modified. Doing so is the behaviour of a (bad quality) grad
On Sun, Jun 2, 2013 at 8:44 PM, Fred Cooke fred.co...@gmail.com wrote:
Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
came to the conclusion that I thought this was anything to do with Git.
Subversion tags, though mutable, should not EVER be committed against or in
Fred, you're the one who mentioned git in that post.
Please remember what stephen pointed out (which I thought was rather nicely
worded): [paraphrased]
The real release is the source bundle, and the tags are
merely a convienance to a developer.
-Chris
On Mon, Jun 3, 2013 at
On Mon, Jun 3, 2013 at 10:52 AM, Benson Margulies bimargul...@gmail.comwrote:
On Sun, Jun 2, 2013 at 8:44 PM, Fred Cooke fred.co...@gmail.com wrote:
Although I prefer to use Git, it's totally irrelevant. I'm unsure how you
came to the conclusion that I thought this was anything to do with
Please stop addressing me. I'm done with this thread. The futility is
killing me. I've *MUCH* better things to do with my time. I'm 110% certain
that 101% of you will be pleased by this. Win win.
Fred.
On Mon, Jun 3, 2013 at 3:27 AM, Chris Graham chrisgw...@gmail.com wrote:
Fred, you're the
On May 31, 2013 12:08 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Yes 3.1.0-alpha-1 has had/will have at least four respins... primarily
because the volunteers have been slow stepping up and testing...
And something not voted on, but with different logger implementations had
And btw. even SNAPSHOTs are nowadays deployed with a timestamp and so more
easily identifiable. I like James approach x.y.z-candidate but would be
happy with steps in z as well.
Regards Mirko
--
Sent from my mobile
On Jun 1, 2013 8:44 AM, Mirko Friedenhagen mfriedenha...@gmail.com
wrote:
On
I will need to recheck the tally, but I think the result is -3
So looks like we will be reusing version numbers on respins
On Wednesday, 29 May 2013, Stephen Connolly wrote:
We have been using a policy of only making releases without skipping
version numbers, e.g.
3.0.0, 3.0.1, 3.0.2,
yes, the vote for one unique rule is clearly -1
but as I see, there seems to be a consensus around a 2-sided rule:
- don't reuse version number for pre-releases (RC, etc)
- reuse version number for actual releases
Regards,
Hervé
Le samedi 1 juin 2013 08:27:38 Stephen Connolly a écrit :
I will
but as I see, there seems to be a consensus around a 2-sided rule:
- don't reuse version number for pre-releases (RC, etc)
- reuse version number for actual releases
Not sure how I feel about that.
alpha/beta/RCx etc, they are all still valid version nos, so I think that
the no re-spin rule
:-) I use a 4 digit no, but I have special requirements. X.Y.Z.N-SNAPSHOT
etc.
-Chris
On Sat, Jun 1, 2013 at 4:50 PM, Mirko Friedenhagen
mfriedenha...@gmail.comwrote:
And btw. even SNAPSHOTs are nowadays deployed with a timestamp and so more
easily identifiable. I like James approach
from a pure technical perspective, yes: a release is a release
but from recent experience, making such difference between pre-releases and
actual releases could give us some flexibility without much disturbance
from my experience, even if this question is not absolutely scm-specific, git
This discussion about respins is really strange to me. I've been cutting
releases, with Maven, at Apache, for years now. And all of them have reused
version numbers for respins. And all of them have carefully used staging
technology (old: directories, new: Nexus) to ensure that artifacts don't
On 31 May 2013 10:22, James Nord (jnord) jn...@cisco.com wrote:
This discussion about respins is really strange to me. I've been cutting
releases, with Maven, at Apache, for years now. And all of them have
reused
version numbers for respins. And all of them have carefully used staging
As pointed out by Benson, the whole skipping thing *should* be a non-issue
anyway. If doing a release you should already know that it's good enough.
You should already have tested it thoroughly on your own OSes. You should
have already requested other devs to build from a hash/buildnumber and
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: 31 May 2013 10:29
To: Maven Developers List
Subject: Re: [VOTE] Should we respin CANCELLED releases with the same
version number?
On 31 May 2013 10:22, James Nord (jnord) jn...@cisco.com wrote
Nice solution, +1.
On Fri, May 31, 2013 at 11:41 AM, James Nord (jnord) jn...@cisco.comwrote:
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: 31 May 2013 10:29
To: Maven Developers List
Subject: Re: [VOTE] Should we respin CANCELLED
Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: 31 May 2013 10:29
To: Maven Developers List
Subject: Re: [VOTE] Should we respin CANCELLED releases with the same
version number?
On 31 May 2013 10:22, James Nord (jnord) jn...@cisco.com wrote
On 31 May 2013 10:41, James Nord (jnord) jn...@cisco.com wrote:
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: 31 May 2013 10:29
To: Maven Developers List
Subject: Re: [VOTE] Should we respin CANCELLED releases with the same
version
So what I am for is the following (example) (which does not re-use version
numbers):
So we have 3.2.12 (released as you currently do).
New breaking API is encountered
So you up the minor version - and create a RC release
That version is 3.3.0-1 (the buildnumber is important)
That fails
I agree with Dan and Wayne
+1 for qualified releases (alpha, beta, RC, etc…) that are working toward the
full blow release but aren't intended to be that.
-1 for the actual releases.
And I don't care if the next 3.1.0-alpha is alpha-2 or alpha-4: what I care is
that it is not alpha-1 any more
+1 for pre-releases (RC, etc)
-1 for actual releases
(non-binding)
/Anders
On Thu, May 30, 2013 at 8:20 AM, Hervé BOUTEMY herve.bout...@free.frwrote:
I agree with Dan and Wayne
+1 for qualified releases (alpha, beta, RC, etc…) that are working
toward the
full blow release but aren't
On Thursday, 30 May 2013, Chris Graham wrote:
What do we currently do for plugins?
What do we currently do for core?
Is there in difference in the approach taken?
No difference. In each case we currently respin failed votes reusing the
version number until we get an actual successful vote.
Thank you Stephen for taking the time to explain.
To me, the key critical bits are:
1. The full normal tag is created, and deleted if failed. If the release
process fails (as in release:prepare/release:perform) we often have to
delete the tag and manually re-run it anyway.
2. The copying process
On 30 May 2013 10:30, Chris Graham chrisgw...@gmail.com wrote:
Thank you Stephen for taking the time to explain.
To me, the key critical bits are:
1. The full normal tag is created, and deleted if failed. If the release
process fails (as in release:prepare/release:perform) we often have to
One more thing to consider:
It's a huge change; as if you do not delete, you now have broken 'releases'
in a SCM somwhere, and that is radically different to what is currently
there.
I should be able to check anything out now from a tag, build it and have it
work.
If we allow broken tags, then
Are you saying that tags for 2.1 and 2.2.0 of Maven itself should be
deleted because those versions are broken? A tag isn't a guarantee of
correctness/non-brokenness, it's just a *permanent* record of what a
particular version contained. The concept of immutability is pretty core to
Maven (at
As far as the ASF is concerned, from a legal perspective, the tag is not a
release.
The only release is the src.tar.gz in the dist folder or the archives.
Tags and binaries are simply a convenience for users.
Whether that is something that is important to the Maven community is a
different
On 30 May 2013 11:38, Fred Cooke fred.co...@gmail.com wrote:
When I first witnessed the deletion of tags
and re-spinning of versions some months ago it was the most disturbing
thing that's happened to me since I found out that Santa Claus wasn't real.
WHAT THE F*CK!!! Are you suggesting to
No, by their own rules, if the vote passed, then it's 'valid' release.
That fact that we have more than one release of anything means that we
sometimes get it wrong.
-Chris
On Thu, May 30, 2013 at 8:38 PM, Fred Cooke fred.co...@gmail.com wrote:
Are you saying that tags for 2.1 and 2.2.0 of
Nicely pointed out.
If a release is strictly speaking, the source bundle, then I have even less
of an objection to respinning a release.
-Chris
On Thu, May 30, 2013 at 8:39 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
As far as the ASF is concerned, from a legal perspective,
Point missed. You said:
It's a huge change; as if you do not delete, you now have broken 'releases'
in a SCM somwhere, and that is radically different to what is currently
there.
And my point was, it's no change at all, there are already broken
releases (without the quotes) in an SCM
No, not at all.
We're talking about removing the latest tag whilst in the process of voting.
My reading of what you wrote, was that you were suggesting to retroactively go
back and remove tags that are not the latest release.
Which I believe is against the apache rules.
-Chris
Sent from my
No, I'd cut off my own hand with a blunt teaspoon before I did that.
On Thu, May 30, 2013 at 3:20 PM, Chris Graham chrisgw...@gmail.com wrote:
No, not at all.
We're talking about removing the latest tag whilst in the process of
voting.
My reading of what you wrote, was that you were
Let me rephrase my vote:
+1 for qualified releases
-1 for actual releases
Robert
Op Wed, 29 May 2013 19:07:59 +0200 schreef Robert Scholte
rfscho...@apache.org:
-1 (binding) on actual releases
Robert
Op Wed, 29 May 2013 15:20:17 +0200 schreef Daniel Kulp
dk...@apache.org:
+1 for
On Thu, May 30, 2013 at 4:55 AM, Stephen Connolly ... wrote:
And I am considering whether I want to change my vote ;-)
I am as well. Fred's comments like:
but I'm not confused by the absence
of 2.7.3 in any way shape or form.
and
The concept of immutability is pretty core to
Maven (at
I will be counting spilt votes like this as the actual release vote... If
we want to finesse for alpha and beta after the principle for releases is
established, we can have another vote...
So to clarify: Robert's vote is currently
-1 reuse version numbers when respinning
On Thursday, 30 May
On Thursday, 30 May 2013, Wayne Fay wrote:
On Thu, May 30, 2013 at 4:55 AM, Stephen Connolly ... wrote:
And I am considering whether I want to change my vote ;-)
Nope I'm sticking with
+1 no reusing version numbers
After Fred pointed out the immutability thing and given that eg tomcat
This discussion about respins is really strange to me. I've been
cutting releases, with Maven, at Apache, for years now. And all of
them have reused version numbers for respins. And all of them have
carefully used staging technology (old: directories, new: Nexus) to
ensure that artifacts don't
Careful there Stephen, we are talking process here, not the specifics of
the git implementation.
-Chris
On Fri, May 31, 2013 at 6:11 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Thursday, 30 May 2013, Wayne Fay wrote:
On Thu, May 30, 2013 at 4:55 AM, Stephen Connolly ...
We have been using a policy of only making releases without skipping
version numbers, e.g.
3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
Whereby if there is something wrong with the artifacts staged for release,
we drop the staging repo, delete the tag, roll back the version, and run
again.
+1 (binding)
On 29 May 2013 11:01, Stephen Connolly stephen.alan.conno...@gmail.comwrote:
We have been using a policy of only making releases without skipping
version numbers, e.g.
3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
Whereby if there is something wrong with the artifacts staged
On Wed, 29 May 2013 11:01:25 +0100
Stephen Connolly stephen.alan.conno...@gmail.com wrote:
+1 (at last ;))
tony (non binding)
+1 (binding)
On 29 May 2013 11:01, Stephen Connolly stephen.alan.conno...@gmail.comwrote:
We have been using a policy of only making releases without skipping
-1
Den 29. mai 2013 kl. 12:04 skrev Tony Chemit che...@codelutin.com:
On Wed, 29 May 2013 11:01:25 +0100
Stephen Connolly stephen.alan.conno...@gmail.com wrote:
+1 (at last ;))
tony (non binding)
+1 (binding)
On 29 May 2013 11:01, Stephen Connolly
-1 (non-binding)
-Lukas
On 05/29/2013 12:01 PM, Stephen Connolly wrote:
We have been using a policy of only making releases without skipping
version numbers, e.g.
3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
Whereby if there is something wrong with the artifacts staged for release,
-1 (nb)
Stephen Connolly wrote:
We have been using a policy of only making releases without skipping
version numbers, e.g.
3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
Whereby if there is something wrong with the artifacts staged for release,
we drop the staging repo, delete the tag,
+1(million) non-binding, but if you want, I'll have your children if you
make this extremely positive change 3
On Wed, May 29, 2013 at 12:31 PM, Jörg Schaible joerg.schai...@scalaris.com
wrote:
-1 (nb)
Stephen Connolly wrote:
We have been using a policy of only making releases without
FWIW, over in Apache Commons land this is how we handle things.
When we prepare and tag a release for version x.y.z, it is tagged as
.../x.y.z-RC1. If the [vote] passes, the tag is copied to .../x.y.z. If the
[vote] fails, the tag stays as a record of what happened and the email
archives tell the
Moving discussion off the vote thread
The issue with that is when using the Maven Release Plugin, you will not be
voting on the released artifacts if you call it x.y.z-RCn, so you would
need a whole new vote for x.y.z.
We could go all Eclipse nutjob and force the timestamp into every release,
On Wed, May 29, 2013 at 7:23 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Moving discussion off the vote thread
The issue with that is when using the Maven Release Plugin, you will not be
voting on the released artifacts if you call it x.y.z-RCn, so you would
need a whole new
Ahh, so that is just a nicer way of handling the respin with same version
number. In any case we currently have a ∑ binding = 0 so no decision
forthcoming yet... but early days ;-)
On 29 May 2013 12:31, Gary Gregory garydgreg...@gmail.com wrote:
On Wed, May 29, 2013 at 7:23 AM, Stephen
It seems that most people care about X.Y and X.Y.Z numbers of the
versioning scheme, not X.Y.Z.N. To spin through version numbers without
concern during release candidates, perhaps using the 4th position, N, would
then allow continued use of the familiar X.Y and X.Y.Z references?
I'm totally fine with the 1.0-RC0 1.0-RC1 1.0-RC2 == 1.0 thing, in Git you
don't even have to copy anything ;-)
If you're going to do trial releases, then RCX is one good way to do it.
I've got to point out, though, that skipped numbers means exactly NOTHING
:-) You *always* skip numbers, by
+1 if it helps to have more regular releases (but I'm not sure it will help)
On Wed, May 29, 2013 at 1:10 PM, Gary Gregory garydgreg...@gmail.comwrote:
FWIW, over in Apache Commons land this is how we handle things.
When we prepare and tag a release for version x.y.z, it is tagged as
On 29 May 2013 20:53, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
The issue with that is when using the Maven Release Plugin, you will not be
...
Can't we fix the tooling then?
-
To unsubscribe, e-mail:
Actually clarified that the release plugin is being used but the tag is
being forced to a different name and then moved post successful release,
e.g.
mvn release:prepate release:perform -DreleaseVersion=3.1.0 -Dtag=3.1.0-RC1
Now there is an issue with that in that the pom will contain the wrong
+1 for qualified releases (alpha, beta, RC, etc…) that are working toward the
full blow release but aren't intended to be that.
-1 for the actual releases.
Dan
On May 29, 2013, at 6:01 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
We have been using a policy of only making
You're voting on a set of sources, and the state of them, more than the
specific binary built on a specific platform. You're not really voting on
the arbitrary binary that manifests itself as a result of those sources and
build. Although it's possible to build from the same sources and get a
-1 (binding) on actual releases
Robert
Op Wed, 29 May 2013 15:20:17 +0200 schreef Daniel Kulp dk...@apache.org:
+1 for qualified releases (alpha, beta, RC, etc…) that are working
toward the full blow release but aren't intended to be that.
-1 for the actual releases.
Dan
On May 29,
Agree with Dan.
+1 for qualified
-1 for actual
Wayne
On Wed, May 29, 2013 at 8:20 AM, Daniel Kulp dk...@apache.org wrote:
+1 for qualified releases (alpha, beta, RC, etc…) that are working toward
the full blow release but aren't intended to be that.
-1 for the actual releases.
Dan
On
Well, from the wording of the VOTE question and what I've read from you
Fred in the past, shouldn't actually be a -1 from you here?
What I read is Should we respin CANCELLED releases with the same version
number? then
+1 = current way of working, just drop the release and re-release (possibly
This vote is to change the policy to:
drop the staging repo, document the release as not released, and run with
the next version.
On Wed, May 29, 2013 at 9:54 PM, Baptiste MATHUS bmat...@batmat.net wrote:
Well, from the wording of the VOTE question and what I've read from you
Fred in the
You're right, my bad. I just re-read the details in Stephen's original mail.
So I'm also:
+1 for pre-releases, dropping everything to reuse numbers is not worth the
hassle
-1 for actual releases: it would create more mess imo for end users if
there's many bizarre jumps in numbering
2013/5/29
-1 for actual releases: it would create more mess imo for end users if
there's many bizarre jumps in numbering
The thing with this argument is that it's very, very weak. If a missed
version confuses a user, they're basically brain-dead. Assuming your users
are brain dead is _always_
Non-bindingly:
+1 for pre-releases
-1 for actual releases
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
On Wed, May 29, 2013 at 10:00 PM, Baptiste MATHUS bmat...@batmat.net wrote:
You're right, my bad. I just
What do we currently do for plugins?
What do we currently do for core?
Is there in difference in the approach taken?
We call for a vot for vX.Y.Z of arbitrary plugin (plugins's [recently at
least] do not appear to go throught he beta/RC phases).
Can someone please spell out a sequence of events
87 matches
Mail list logo
