It should be as easy as http://svn.apache.org/r1669762
Again: custom VersionPolicies aren't exposed yet by the plugin. I've added
this, so we have time to complete the API, e.g. do we have enough
information to predict the next version? In the end it is just a matter of
writing proper unitt
On 23 February 2015 at 13:45, Lennart Jörelid
wrote:
> Hello all again,
>
> This is exactly my experience with large reactors; while semver would be
> the desired way to go it is impractical bordering on impossible to combine
> semver for a large number of projects. (In fact, it boils down to man
Hello all again,
This is exactly my experience with large reactors; while semver would be
the desired way to go it is impractical bordering on impossible to combine
semver for a large number of projects. (In fact, it boils down to manually
correctly managing all versions within a release.propertie
On Sun, Feb 22, 2015 at 10:42 PM, Fred Cooke wrote:
> I'd also love to hear that no one is trying to release 200 artifacts in a
> single reactor.
At Wicket Stuff (https://github.com/wicketstuff) we do just that. It
is a pain, but
it is quite a lot less pain than trying to release each project by
That makes some sense, but a more generic big project where the life cycle
of each component is distinct and meaingfully distinct, it does not. I can
think of another good case, albeit with a much lower number of moving
parts: Parent sets. It's nice to have only one current version number to
rememb
On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke wrote:
>
> I'd also love to hear that no one is trying to release 200 artifacts in a
> single reactor. That makes no sense at all, to me. The chances are on a big
> corporate project you've only changed <25% of them per top level release
> anyway. So to
It's worth pointing out that if you just run the two part version in the
first place you are doing the same thing. IE, internally maven's versions
are always x.y.z even if you only specify x.y thus if you have 2.6 and
you're doing SemVer (2+, 1 sucked), then it'll behave correctly. Add the
patches
Thanks Robert,
I'll have a look at it.
On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte wrote:
> Hi Dennis,
>
> I've already started to extract some parts of the maven-release-manager to
> an API.
> The project has now 4 modules[1], whereas the maven-release-apis[2] should
> be interesting.
> I'v
Hi Lennart,
There's a github mirror for all Apache projects:
https://github.com/apache/maven-release
thanks,
Robert
Op Sun, 22 Feb 2015 16:03:51 +0100 schreef Lennart Jörelid
:
Hello Robert,
I figured I'd take a look at this to possibly throw in some
ideas/experiences from earlier project
Hello Robert,
I figured I'd take a look at this to possibly throw in some
ideas/experiences from earlier projects.
Is there a Git mirror available?
2015-02-22 13:00 GMT+01:00 Robert Scholte :
> Hi Dennis,
>
> I've already started to extract some parts of the maven-release-manager to
> an API.
>
On Sun, Feb 22, 2015 at 7:43 AM, Lennart Jörelid
wrote:
> Well ... actually, Benson, the project I'm thinking of had 398 maven
> projects within one deliverable.
> Roughly divide by 3 to get the number of APIs there - implying the number
> of API projects are at the 130+ level.
>
> However - just
Well ... actually, Benson, the project I'm thinking of had 398 maven
projects within one deliverable.
Roughly divide by 3 to get the number of APIs there - implying the number
of API projects are at the 130+ level.
However - just throw into the mix that you are creating a 100% uptime
project where
Hi Dennis,
I've already started to extract some parts of the maven-release-manager to
an API.
The project has now 4 modules[1], whereas the maven-release-apis[2] should
be interesting.
I've started with a VersionPolicy interface, Simone already started on his
own implementation of OddEven P
On Sun, Feb 22, 2015 at 6:26 AM, Lennart Jörelid
wrote:
> Actually, Dennis, I would argue that your problem is the smaller one of the
> two main problems with the release plugin.
>
> The bigger problem is that the release plugin requires too much manual
> fiddling to apply in a big maven reactor.
Actually, Dennis, I would argue that your problem is the smaller one of the
two main problems with the release plugin.
The bigger problem is that the release plugin requires too much manual
fiddling to apply in a big maven reactor. For example; given a reactor with
250+ maven projects you want to
This is also my problem with release plugin.
I am missing version schema in .
I guess BashShell code or some other generic approach because there might be
a lot of rules the users may require.
--
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSS-To-SemVer-or-not-to-SemVer
Hello,
I know its not your problem domain, but I wanted to point out that the
OSGi bnd-tool can do exactly that. It can even differentiate for
interface providers and consumers.
http://www.aqute.biz/Bnd/Versioning
However the question is, if it really works all automatic if you are
not strictly
Hi,
Although I strongly feel that SemVer [1] is the way to go when it
comes to versioning, I still haven't started using it though. That got
me thinking about why that is the case. I've come to the conclusion
that I'm lazy :)
It all comes down to tooling. Being accustomed to, and spoiled by,
usin
18 matches
Mail list logo
