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
