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,
ok, the auto installer ant_maven.groovy script gets every released Maven
version from our official release area [1]
Then *any released* version will be available: once Maven 3.1.0-alpha-1 will
be released, it will be shown by this script, ready to have many eyes, even if
this release is only
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
Here are the release bits for 3.1.0-alpha-1:
Release notes:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967
Staging repository:
https://repository.apache.org/content/repositories/maven-046/
Staged distribution:
I need some feedback on informations to display. I propose my (limited)
vision.
mvn clean install site
http://svn.apache.org/repos/asf/maven/sandbox/trunk/dist-tools
database of artifacts to check is not complete, loosely based
on artifacts plugins from
pfew, really nice!
It would be nice if reports started by an explanation of points checked: that
would ease understanding the content following, because dist-tool-checkstyle
report in particular is hard to understand (check summary, Stylus Skin?,
Fluido Skin?)
But it is really a wonderful
Hi Jesse,
Am 20.05.2013 17:28, schrieb Jesse Glick:
On 05/16/2013 05:42 PM, Jörg Hohwiller wrote:
is there already some slight inital draft or idea for a strategy how
maven x.y could deal with jigsaw?
I wrote up a very preliminary sketch about a year ago [1] but have not
worked on it since
+1 (non-binding) for (c726cdd3a9ad5c3a419e1171f8c1925e336ead18):
- I successfully ran mvn verify site for some of my own projects
(pom-only, one jar, multi-module).
- the current trunk of maven-javadoc-plugin encountered some failing ITs.
[ERROR] * additionnal-dependencies-non-aggregate/pom.xml
13 matches
Mail list logo
