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 remember when you're poking around your POM and spot the parent tags. In this case I'd rather have duplicate releases because as a set, they work together well, or so it should be.
Strict adherence to SemVer is a bit of a fail anyway, provided your versions have semantic meaning that is well defined within their context, you're doing well. For example, your long lived release branches. On Mon, Feb 23, 2015 at 5:09 PM, Chris Graham <chrisgw...@gmail.com> wrote: > On Mon, Feb 23, 2015 at 8:42 AM, Fred Cooke <fred.co...@gmail.com> 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 run a top level MVN release against the entire tree would > > produce 75% duplicate (by code, not number) artifacts. Or did I > > misunderstand? > > > > From a pragmatic, not a SemVer point of view, it makes a lot of sense. I > can think of some Message Broker projects that I did, with a few hundred > message sets. You're right, in that the % change is minimal. The issue is > that it's rarely the same modules that change. And in that sense, setting > up the SCM tagging would be a nightmare. > > So, what I've done is to set up a monolithic build, where I rebuild > everything everytime, and release everything time. So it's not SemVer, but > it works. I can verify the SCM provenance of the code with a single tag. > The only thing that defines a vesion, is that it's different, in some way, > to another another version. > > In message brokers case, it drastically simplifies the deployment options, > it's simple as everything gets deployed each and every time. Automating the > deployment of a single message set across any given number of bar files > into whatever execution groups require it would be next to impossible (and > not worth the effort in doing so). > > I used long life release branches (a release of X.Y lives in it's own > branch, in some cases up to 18 months), with many releases of > X.Y.Z-SNAPSHOT on the branch. The last project used Oracle CC&B, and we > have 5 concurrent release branches. SemVer in that instance is not doable. > > So yes, the same code will be tagged multiple times, with different > versions with no real changes to the module. And that is fine. You've also > got to remember that I set the maven builds up underneath the devs, so that > they were not aware of it, other than this strange looking pom.xml that > suddenly appeared in their projects :) >
