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 remote.
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
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
>
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 develo
+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é B
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, bu
Hi,
We solved 29 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=18308
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11126&status=1
Staging repo:
https://repository.apache.org/co
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 wrote:
> So what would you propose the optimal behaviour would be?
>
> On Nov
So what would you propose the optimal behaviour would be?
On Nov 14, 2012, at 3:54 PM, Mark Hobson 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 patch if that real
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
2012/11/14 Karl Heinz Marbaise :
> 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?
git repo is
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
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 wrote:
> I have put together a simple roadmap using JIRA macros in Confluence to try
> and communicate to users wha
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 wrote:
On Nov 14, 2012, at 4:28 AM, Kristian Rosenvold
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 production and I'm not changi
2012/11/13 Manfred Moser :
> 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 version stuff sh
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 :
> I have put together a simple roadmap using JIRA macros in Confluence to try
> and communicate to users what we're planning to do.
>
> https://cwik
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 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.
>
> https://cwiki.apache.org/confluence/display
18 matches
Mail list logo
