Cris,
Hmm. I'm not seeing the disagreement.
Can you give an example of a change between kinds of versions that
Semantic Versioning would allow but the description in UP-4146 would
forbid, or vice versa?
Andrew
On 6/19/14, 12:10 PM, Cris J Holdorph wrote:
There seems to be a difference in the Semantic Versioning you quoted
and what you put into the Jira UP-4146. Specifically in this point.
Semantic Versioning quote:
2. MINOR version when you add functionality in a backwards-compatible
manner
In UP-4146
starting with the uPortal 4.2 release, *no new features* in the 4.2
maintenance branch. Emphatically backwards-compatible bugfixes only.
Those don't seem to be in agreement to me.
---- Cris J H
On 06/18/2014 09:35 AM, Andrew Petro wrote:
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]
<mailto:[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
