A very big +1 for 6-8 weeks release cycles for core!
/Anders
On Tue, Nov 13, 2012 at 9:25 PM, Jason van Zyl ja...@tesla.io wrote:
I have put together a simple roadmap using JIRA macros in Confluence to
try and communicate to users what we're planning to do.
Jason;
Can you submit thread-safe local repository to apache for 3.1 or will
I have to reimplement that too ?
Kristian
2012/11/13 Jason van Zyl ja...@tesla.io:
I have put together a simple roadmap using JIRA macros in Confluence to try
and communicate to users what we're planning to do.
2012/11/13 Manfred Moser manf...@mosabuam.com:
True... separate, but closely related. If we state that semver is the
recommended practice (and I believe that to be a good idea) .. the whole
tooling should work nicely with it. And that includes the use case I
mentioned..
And yes.. maybe the
On Nov 14, 2012, at 4:28 AM, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
Jason;
Can you submit thread-safe local repository to apache for 3.1 or will
I have to reimplement that too ?
The implementation here[1] I won't be submitting as that's been running for two
years in
I plan to add some addition text in the roadmap with the overall objectives
along with the issues as I think we've become opaque again regarding the
deliverables. Maven is used so widely users just expect more information about
what's coming.
On Nov 14, 2012, at 4:23 AM, Anders Hammar
Just a reminder that there are six issues still in there without owners for
3.1.0. I'll flush those out tomorrow if no one claims them.
On Nov 13, 2012, at 3:25 PM, Jason van Zyl ja...@tesla.io wrote:
I have put together a simple roadmap using JIRA macros in Confluence to try
and communicate
Hi,
I'm particular interessted in http://jira.codehaus.org/browse/MNG-5091...
for the issue an patch already exists...I can help ...
The question is what exactly i can do?
Just use the maven-3 git repo on GitHub or better Apache SVN Repo?
Can someone give a kind of guidance...
Furthermore i
2012/11/14 Karl Heinz Marbaise khmarba...@gmx.de:
Hi,
I'm particular interessted in http://jira.codehaus.org/browse/MNG-5091...
for the issue an patch already exists...I can help ...
The question is what exactly i can do?
Just use the maven-3 git repo on GitHub or better Apache SVN Repo?
Hi all,
I see Jason's suggested MNG-3092 [1] for 3.1.0, which is great, but as
the comments show this is a political hot potato. I'm happy to apply
my original patch if that really is the consensus?
Thanks,
Mark
[1] http://jira.codehaus.org/browse/MNG-3092
So what would you propose the optimal behaviour would be?
On Nov 14, 2012, at 3:54 PM, Mark Hobson markhob...@gmail.com wrote:
Hi all,
I see Jason's suggested MNG-3092 [1] for 3.1.0, which is great, but as
the comments show this is a political hot potato. I'm happy to apply
my original
Personally I'd like to see it adhere to the original specification.
Whether that's optimal depends on what development process is being
used, as reflected in the comments.
Mark
On 14 November 2012 21:44, Jason van Zyl ja...@tesla.io wrote:
So what would you propose the optimal behaviour would
Hi,
We solved 29 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=18308
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11126status=1
Staging repo:
no
core only needs to compare version
core never need to calculate next version
some plugines like release or versions need to try to guess which is the next
one: nothing that belong to core IMHO
Regards,
Hervé
Le mardi 13 novembre 2012 14:28:18 Manfred Moser a écrit :
True... separate, but
+1 version incrementing logic should be a shared component not a part of
core.
Also I wonder if we shouldn't formalise the ability to scope versioning
systems per groupId:artifactId though that could merit being part of
core... And is somewhat political too
On Wednesday, 14 November 2012, Hervé
So we've flipped the behaviour back and forth now, yes?
I think there are use cases for both types of behaviour.
If you are in snapshot mode yourself, you probably want snapshots to be
resolved in ranges for your stuff (however we might categorize that, maybe
groupId). When you're not in
Sure... not core then. But ideally some shared library that implements
that so all plugins that need to do it can do it consistently the same..
manfred
On Wed, November 14, 2012 3:17 pm, Hervé BOUTEMY wrote:
no
core only needs to compare version
core never need to calculate next version
Github user jdillon closed the pull request at:
https://github.com/apache/maven-surefire/pull/7
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I had created a hack of the clirr plugin at a prior employer to compute the
next version number a few years ago (rejected by the mojo project, as
the owners didn't want to start breaking builds with clirr)
We had 50-60 jars and 20+ developers with a range of skill/java knowledge,
some
18 matches
Mail list logo
