+1
tested with Maven core and ITs
Regards,
Hervé
Le jeudi 12 septembre 2013 13:29:32 Tamás Cservenák a écrit :
Hi,
We solved 6 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335version=19
092
There are still a couple of issues left in JIRA:
Json,
the JDK7 just went from 25 to 40 for me and I do not mind :-)
Regards Mirko
--
Sent from my mobile
On Sep 15, 2013 2:00 AM, Jason van Zyl ja...@tesla.io wrote:
The users may well be developers, but I don't think that warrants changing
a normal pattern. Maybe only I consider this a
Thanks for the hints Martin.
Unfortunately they didn't work.
I don't think the problem is on the client side though, since I get
the same error on both Windows and Ubuntu.
Here is the error message I get using the standard Subversion 1.6
command line client:
svn: File not found: transaction
http://svn.apache.org/r1523427
so it's indeed a client issue.
I've used:
TortoiseSVN 1.7.12, Build 24070 - 64 Bit , 2013/03/29 08:00:43
Subversion 1.7.9
Robert
Op Sun, 15 Sep 2013 12:50:28 +0200 schreef Dennis Lundberg
denn...@apache.org:
Thanks for the hints Martin.
Unfortunately they
Hi
I won't get into the debate as to which process is best at this time,
as I think they both have merits and drawbacks. Until I'm convinced
one way or the other I prefer to continue doing business as usual.
Here are a couple of large open source projects that do not publish
*distributions* of
Hello,
IMO as long as only patch-levels (micro-versiony) are skipped, no harm
should come from skipping.
Regards Mirko
--
Sent from my mobile
On Sep 15, 2013 1:03 PM, Dennis Lundberg denn...@apache.org wrote:
Hi
I won't get into the debate as to which process is best at this time,
as I
That someone might have been me.
I did an internal poll to ask if people would understand if Maven would
jump from 3.0.5 to 4.1.3.
None of them did, they all wondered what happened to the missing versions.
Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.
One major
But you asked the wrong jump then.
It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
if we have not had a 4.0.x released at all.
My point is patch version people are perfectly fine with skips Minor
version skips would be bad, but there is zero need for them.
On
Your poll is a special case, which was separated in the discussions. For
all cases, but especially your special case, a good solution is to do what
some other ASF project does, and vote on SCM, then release once. They build
snapshots (gasp, maven concept in use, and IIRC they don't even use
Exactly! :-)
On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
But you asked the wrong jump then.
It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
if we have not had a 4.0.x released at all.
My point is patch version
Thanks a lot Robert!
It was indeed an svn client issue.
Using Subversion 1.7.13 from the command line worked fine, after
upgrading my working copy.
However my Java based desktop app, which uses the TMate library, was
unable to commit the files. The error message was different though.
On Sun,
Another data point is exactly how many times have we got patch release .0 right?
2.1.0 - seriously borked use 2.2.1
2.2.0 - seriously borked use 2.2.1
3.0.0-3.0.2 - not recommended for use
3.0.3 - ok but has issues with release plugin
3.0.4 - first 3.x that could be considered stable
3.1.0 -
Some other ASF PMCs have no qualms about skipping version numbers.
For example AIUI Tomcat creates a release candidate, and if the vote
fails, they bump the patch version.
For example they released 7.0.30 and 7.0.32; there is no 7.0.31.
The other point I would make is that bumping the way the
That's why I said to use branches. Braches XOR skip versions. I prefer the
latter, though they can be mixed too.
On Mon, Sep 16, 2013 at 1:22 AM, sebb seb...@gmail.com wrote:
Some other ASF PMCs have no qualms about skipping version numbers.
For example AIUI Tomcat creates a release
On Sun, Sep 15, 2013 at 3:24 AM, Jason van Zyl ja...@tesla.io wrote:
When a release fails like this it is annoying to have to rev back the
version of the POM. I'm not sure who flipped the versions in the POM and
while it's a little more visible to see what you're moving toward I prefer
the
There was an old JIRA floating around to make that combination the default for
git/mercurial and other distributed version control tools.
Not sure what ever happened to that tho. We add that configuration to every
project we do with git.
On 15/09/2013, at 6:20 AM, Mark Struberg
16 matches
Mail list logo
