Hi folks, I agree that changing from 1.major.minor to major.minor would be confusing for users. I don't really have a horse in this race, but if I were trying to make a move from 1.major.minor to major.minor, I'd do it like the Java versions, so that users might have a chance at being familiar with it. For example,
old scheme -> new scheme 1.7.0 -> 7.0.0 1.8.0 -> 8.0.0 etc So if the project *must* renumber closer to semver (dropping the leading "1." in front of every version), then at least users will be familiar with it that are familiar with Java version numbers (though unlike Oracle, I'd eventually try to drop the 1.x designations). I don't really have strong feelings about the actual change. Just something I was thinking about while reading the thread. Hope it's a useful observation! - Martin Smith mar...@mbs3.org ________________________________________ From: Andrew Gaul [g...@apache.org] Sent: Monday, August 25, 2014 11:00 AM To: dev@jclouds.apache.org Subject: Re: major release cadence On Sun, Aug 24, 2014 at 02:28:18PM +0200, Andrew Phillips wrote: > >Given the lack of positive feedback to semantic versioning > > Sorry, a bit behind in catching up with emails. To me, the rough > timing of releases and decision on breaking changes are indeed the > main two points, which seem fine to me. Prior to this thread we introduced breaking changes in major releases, as defined by 1.7 -> 1.8, and released minor releases, as defined by 1.7.0 -> 1.7.1, every 6-8 weeks. Earlier in this thread we agreed to major releases every 6 months, again defined as 1.7 -> 1.8. > I'm also fine with semantic versioning, but agree that we can move > forward on the former two points and leave this for later if > necessary. I don't immediately see any obvious areas where the > transition cost would be that big. > > Could you elaborate on the challenges you see there, Andrew G? If we were starting a new project, I would not care as much for which versioning scheme we chose. However, we have an existing practice which developers and users already understand and I see benefits to continuing for consistency, outweighing the purported and modest benefits of other schemes. Specifically, users expect today that X.Y+1.0 upgrades can introduce breaking changes and delay upgrading to these releases. Changing this requires messaging to our users, similar to other transitions with source control, bug tracking, and mailing lists. Further other projects have changed versioning schemes, such as Firefox and Java, which caused user confusion without discernible benefit. -- Andrew Gaul http://gaul.org/
