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 parts must be upgradeable at all times. That implies something like OSGi - which means that all Implementation, SPI and Model projects must *also* adhere to semver. Otherwise you cannot simply replace an implementation with a bugfixed one while the app is running.... ... so I would claim that there are scenarios where semver is required for all the project parts. And that the release plugin in its current state is close to unuseable in catering for these scenarios. 2015-02-22 12:44 GMT+01:00 Benson Margulies <bimargul...@gmail.com>: > On Sun, Feb 22, 2015 at 6:26 AM, Lennart Jörelid > <lennart.jore...@gmail.com> 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. For example; given a reactor > with > > 250+ maven projects you want to make a new release since 74 of these 250+ > > projects now contain changes following 4 refactorings. The question now > is > > not one of which semantic versioning principle I'm applying but simply > one > > of practicality: > > > > Which of the 74 projects should now receive a major, minor or micro > version > > upgrade? > > I would be somewhat in awe of a project that included 74 components > that all (or even most) published an API that needed SemVer. My point > here is commentary on yours, not an argument. In my experiment, > typically a multi-module monster has one 'api', and then a complex > internal structure. To the outside world, SemVer applies to the API, > not to all the insides. Or, it applies to the union. If the pieces are > so independent that your scenario applies, I would wonder if a > multi-module structure is really appropriate. > > > > As deliverables scale, the burden of using a proper versioning scheme is > > simply that there is no tooling support in figuring out if a change in > > project X should yield a major, minor or micro version bump - and doing > > this manually is simply not a scalable task at all. > > > > The release plugin seems fine to use when it comes to smaller projects > such > > as most of the maven plugins, but it has distinct usability problems for > > bigger reactors. Release managers in most of my later projects simply > > decided that the only sensible solution was to (re-)release all projects > in > > the reactor with new versions. This implies that most of the maven > > component projects misuse semver, but that the release process works.... > at > > all. > > > > I believe that we need a plugin which could calculate a suggested version > > for a project given the last release's binary API and changes since the > > last release (in the style of clirr + something else). Such a plugin > would > > also be really useful in a continuous delivery scenario where semver is > > needed but largely ignored due to technical difficulties in calculating > > version numbers. > > > > > > > > 2015-02-21 23:05 GMT+01:00 Dennis Lundberg <denn...@apache.org>: > > > >> 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, > >> using the Release Plugin, I don't want to do anything manually any > >> more. That includes as simple a thing as changing the "next version" > >> (or developmentVersion) manually during the interactive command line > >> session when using the Release Plugin. I want it to be the guessed > >> correctly for me. Let me outline an example to show you what I mean. > >> The vast majority of releases I make, both here and at my day job, are > >> minor releases. So I want the Release Plugin to work for me, and not > >> against me. > >> > >> > >> Not using SemVer > >> > >> 1.0-SNAPSHOT --> 1.0 --> 1.1-SNAPSHOT > >> > >> No problems here, the Release Plugin will correctly guess that > >> 1.1-SNAPSHOT is the next version that I want to use. Just hit <enter> > >> a couple of times during the release process. > >> > >> > >> Using SemVer > >> > >> 1.0.0-SNAPSHOT --> 1.0.0 --> 1.0.1-SNAPSHOT > >> > >> This is not what I want. The Release Plugin will guess that the next > >> version should be 1.0.1-SNAPSHOT. To change it I have to type in the > >> value that I want on the command line. I'm too lazy for that. Instead > >> I want the Release Plugin to do this: > >> > >> 1.0.0-SNAPSHOT --> 1.0.0 --> 1.1.0-SNAPSHOT > >> > >> > >> How can we solve this? The solution that I have come up with is a new > >> parameter for release:prepare tentatively called "versionIncrement" > >> that can take the values "major", "minor" and "patch", with "patch" > >> being the default value for backwards compatibility. > >> > >> In my use case above I would simply set versionIncrement=minor and the > >> Release Plugin would then do things my way. > >> > >> What are your thoughts on this? > >> > >> I would like for us to start using SemVer for all releases in the > >> Maven project, not just in core. What do you think? > >> > >> > >> [1] http://semver.org/ > >> > >> -- > >> Dennis Lundberg > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > > > -- > > > > -- > > +==============================+ > > | Bästa hälsningar, > > | [sw. "Best regards"] > > | > > | Lennart Jörelid > > | EAI Architect & Integrator > > | > > | jGuru Europe AB > > | Mölnlycke - Kista > > | > > | Email: l...@jguru.se > > | URL: www.jguru.se > > | Phone > > | (skype): jgurueurope > > | (intl): +46 708 507 603 > > | (domestic): 0708 - 507 603 > > +==============================+ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
