Now tracked in JIRA and tagged for uPortal 4.2. https://issues.jasig.org/browse/UP-4146
On Wed, Jun 11, 2014 at 9:23 AM, Andrew Petro <[email protected]> wrote: > uPortal folks, > > I would like to start floating the Semantic Versioning balloon and see if > it can earn mindshare. > > Currently our practice is to add both minor new features / enhancements > and bugfixes in patch releases. > > I think our practice should change to bugfixes-only in patch releases, and > do more frequent minor releases to get new features out. > > Cf. Semantic Versioning: > > http://semver.org/ > > Here's the summary: > > [ > Summary > > Given a version number MAJOR.MINOR.PATCH, increment the: > > 1. MAJOR version when you make incompatible API changes, > 2. MINOR version when you add functionality in a backwards-compatible > manner, and > 3. PATCH version when you make backwards-compatible bug fixes. > > Additional labels for pre-release and build metadata are available as > extensions to the MAJOR.MINOR.PATCH format. > > > ] > > I expect that this change in practice would be all upside. > > It would make patch releases less risky and less complex, and so would > make it more feasible to cut them more often and for adopters to upgrade > along the patches branch to later patch releases more often. No new > features to figure out how they relate to what you're doing, just > bugfixes. Easier to understand, easier to accept, clearer what you're > getting. > > It would make clearer what a minor release vs a patch release is and why > it becomes time to cut a minor release and what you get for your minor > release. > > It would move uPortal to align with Semantic Versioning, which is a > thing. Even a good thing. > > I'm in-progress cutting the 4.0.14 release, and that's still a > non-semantic-versioning patch release with some new stuff in it. Fine. I > expect we ought not to change strategies for what the 4.1.x patches line > looks like, since 4.1.0 is scoped and being released under the expectation > that it can be patched with enhancements to backfill gaps. Also fine. > > So, if this balloon flies, perhaps the version to adopt Semantic > Versioning in would be uPortal 4.2, and with that in mind we work towards a > 4.2.0 suitable for treating in this way post-4.1.0-release, and this all > fits into the broader theme of evolving uPortal to be and to be treated > more like a product. > > Note that adopting Semantic Versioning says absolutely nothing about the > timeline on which bugfix and new feature releases are released. It's just > about what we call them and how we set adopter expectations about what kind > of changes happen where. There's no rule that we couldn't cut minor > releases even monthly to promptly get those new features out to adopters if > there's that kind of progress being made in the codebase; calling those > minor releases is just a clearer way to communicate about what they are. > > This also fits into a story arc of working towards defining and exposing > versioned APIs. When the codebase is mostly a monolithic bucket containing > both APIs and implementations, nudging them forward all together in a > patches branch, well, it's mostly worked for us. But if the product begins > to get more deliberate about separating, defining APIs and separating them > from implementations, works to enable better strategies and more execution > on developing plugins with sourcecode not sitting right in the uPortal > codebase, well, that's going to go a lot better under Semantic Versioning. > > Kind regards, > > Andrew > > PS: My endorsement of SemVer does not, of course, imply any endorsement of > its author. > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
