uPortal developers, I¹d gotten some off-list concern about the wisdom of adopting Semantic Versioning in uPortal. In the course of thinking through that, I¹ve had occasion to re-articulate why uPortal ought to adopt Semantic Versioning.
http://apetro.ghost.io/uportal-should-semver/ I remain convinced this is the right move for uPortal. Andrew On 6/19/14, 12:48 PM, "Andrew Petro" <[email protected]> wrote: >Aaron, > >I'm glad to hear this is resonating with you! > >I think you're right, that the meaning of uPortal product version >numbers would be more readily apparent under Semantic Versioning and >that this will help as uPortal products evolve to better define APIs. > >I didn't emphasize in my initial writeup, but would if I had to do it >over again, this advantage: reducing the need to apply new features to >multiple development branches. Git helps, but it's still a drag to, for >each feature, consider whether it goes into just master or into master >and 4.0-patches, and if it goes in both, to track that to completion and >adjust to meld appropriately with the differences between those >branches, and... I think it'll be healthier to only be dealing with >applying changes to multiple branches when they're pointed bugfixes. > >Kind regards, > >Andrew > > >On 6/19/14, 10:22 AM, Aaron Grant wrote: >> Hi Andrew, >> >> I think it is smart to move over to this way of thinking for releases. >> Many of my colleagues here that don't work with Apereo software often >> are confused by the releases and how they are organized and I think >> this would clear that up. It might be good to adapt a similar strategy >> with portlets also, as I see us probably exposing APIs for portlets to >> help with mobile app development. >> >> Aaron >> >> On Wed, Jun 11, 2014 at 10: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: >>> >>> MAJOR version when you make incompatible API changes, >>> MINOR version when you add functionality in a backwards-compatible >>>manner, >>> and >>> 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
