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
