On Sun, Feb 22, 2015 at 7:43 AM, Lennart Jörelid <lennart.jore...@gmail.com> 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 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.
Yow! ok, point taken. > > > 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 > +==============================+ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
