I finally had a chance to quickly review the write up. Nice job on the
write up. I'm all for semantic versioning as a concept, and I think
releasing 4.2.0, 4.3.0, etc. on a fairly frequent, regular basis
(quarterly seems fine) makes quite a bit of sense.
Perhaps I misunderstand, but I did have some concerns about having
api-breaking changes hanging out in feature branches for large periods
of time (up to 18 months per suggested schedule) because I see that as
being a risk and a maintenance hassle. It runs the risk of those
feature branches becoming stale and adopters having to pick and choose
feature branches. I like master having the latest of everything
integrated into it. If we are truly doing something toward 'moving the
decimal', then master should remain the latest and greatest of all
accepted changes and we selectively back-port feature additions into the
rel-4-x-patches like we used to with the 4.0.x line and periodically
release minor versions.
Let me know if I misunderstood.
Thanks,
James Wennmacher - Unicon
480.558.2420
On 09/08/2014 12:55 PM, Andrew Petro wrote:
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
