Sure, that makes more sense. Perhaps it's the lack of an example of a
three part version number in the UP-4146 description that had me
confused. Right now, UP-4146 only mentiones "4.2", "4.3" and "5" in the
description. Your description below is more concrete to me and talks
about "4.2.1" and so on.
---- Cris J H
On 06/19/2014 11:06 AM, Andrew Petro wrote:
Cris,
Ah.
I think our miscommunication is coming from keeping track of how the
labels "minor" and "patch" apply to different release numbers and to
maintenance branches.
> Semantic versioning says "you add functionality"
Add (backwards-compatible) functionality for MINOR releases, like 4.3
will add functionality beyond 4.2.
> UP-4146 says "no new features".
No new features in maintenance branches leading to PATCH releases, so no
new functionality in 4.2.1 beyond the functionality in 4.2.0.
To take the example of a new backwards-compatible footer toggle adding
GumGum integration, after 4.2.0 is released, that new feature could come
into master towards 4.3.0, but it could not come into 4.2-patches
towards 4.2.1.
Clarifying?
Andrew
On 6/19/14, 12:46 PM, Cris J Holdorph wrote:
2. Semantic versioning says "you add functionality"
UP-4146 says "no new features".
those seem in disagreement to me. Maybe it's just an interpretation
of the word "functionality" and the word "feature", but to me those
seem like direct opposite statements. One is saying "you do
something" and the other is saying "you don't do something".
As a specific example, lets invent some new toggle that appears in the
footer. When you press this toggle is does "cool thing". Now, this
new toggle in the bottom has no "backward compatibility" problem, it's
just a new cool toggle.
According to the point 2 in semantic versioning, that seems like it is
allowed, because it is new functionality that is backward compatible.
According to UP-4146, it says "no new features", so it would not be
allowed.
---- Cris J H
On 06/19/2014 10:40 AM, Andrew Petro wrote:
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 <ape...@wisc.edu
<mailto:ape...@wisc.edu>> 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 uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
