Fedora Release Schedule and Semantic Versioning

[Andrew Woods]

Hello All,

Two points have been raised in the past and again more recently relating to predictable Fedora releases and semantically meaningful version numbers.

In terms of predictable releases, what we hear is that Fedora releases happen too frequently and at irregular intervals which makes it challenging to keep up to date with Fedora developments and also challenging to build time into local schedules to consistently participate in release candidate testing.

In terms of semantically meaningful version numbers, what we hear and know is that “Fedora 4” branding has encroached on the proper use of semantic versioning. In semantic versioning, each of the three positions of the version number have very specific meaning [1]. 

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.

Due to the branding of “Fedora 4”, we have been reluctant to increment the MAJOR version number beyond “4” as would be dictated by standard semantic versioning.

Given the above, we would like to offer the following suggestion:

===

Fedora should have two releases per year, one in April and the other in October. Additionally, these releases should employ standard semantic versioning.

===

Your feedback on this suggestion would be greatly appreciated. Or if you have another suggestion, that would be welcomed as well.

Regards,

Andrew

[1] http://semver.org/

[David Chandek-Stark]

Andrew,

Two points:

- Given the current instability of the code base, two releases per year would seem insufficient.

- What does "standard semantic versioning" mean specifically for Fedora 4?  I assume it means the major version will not be stuck on "4".  If so, will that not introduce a different sort of confusion: "What version of Fedora 4 are you running?  We're on Fedora4 8.1.2." 

Thanks,

David

[Andrew Woods]

Hello David,

- If what you mean by "instability of the code base" is that the current codebase is actively being developed, that would just mean that in the short-term there would likely be more commits in a given release than potentially in the future. And, if necessary, the bi-annual releases may be major releases. Is it more helpful to instead have more releases per year?

- Correct, if the Fedora project were to go with the approach of employing semantic versioning, the major version would not be stuck on "4". Additionally, we would likely get away from the "Fedora 4" branding and just call the project "Fedora". 

In terms of confusion, that is the exact point of this email thread: to gain common understanding before moving forward with such an approach.

Regards,

Andrew

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.

For more options, visit https://groups.google.com/d/optout.

[David Chandek-Stark]

Andrew,

By "instability" I do not mean "actively developed", I mean "evolving and settling" as it states in https://wiki.duraspace.org/display/FF/Policy+-+Previous+Versions+Support.

--D

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.

[Benjamin Armintor]

The semantic versioning proposal would be a healthy one, I think.

The scheduled release proposal I am less sympathetic to. Are we to just maintain a log of known issues, and move everyone to snapshot releases until the next release comes around? Can an advocate for that schedule identify another open source project that works that way?

- Ben

On Wed, Oct 12, 2016 at 10:31 AM, Mike Giarlo <mjgi...@stanford.edu> wrote:

David,

Part of a move to semantic versioning for Fedora would, IMO, necessitate a shift in branding away from "Fedora 4" and back towards "Fedora." (Same as it ever was...)

Andrew didn't propose that specifically, but I assume that's part of the package for the reason you mention. "Fedora4 8.1.2" should never be a thing. I suspect we can all agree on that. Maybe?

-- 
Michael J. Giarlo

Technical Manager, Hydra-in-a-Box project

Software Architect, Digital Library Systems & Services

Stanford University Libraries

---

From: fedor...@googlegroups.com <fedor...@googlegroups.com> on behalf of David Chandek-Stark <david.cha...@duke.edu>
Sent: Wednesday, October 12, 2016 07:18
To: Fedora Tech
Cc: fedora-community@googlegroups.com; hydra...@googlegroups.com; isla...@googlegroups.com; fedora-leaders@googlegroups.com
Subject: [fedora-tech] Re: Fedora Release Schedule and Semantic Versioning

 

Semantic Versioning 2.0.0 - Semantic Versioning semver.org Semantic Versioning 2.0.0 Summary. Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when ...

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+unsubscribe@googlegroups.com.

[Andrew Woods]

Hello Ben,

In terms of bi-annual releases, that is somewhat arbitrary and is open for refinement. 

The point is that it would be helpful for community planning purposes to have scheduled and regular releases. If I have misheard the desire from the community to have scheduled and regular releases, that would be good to know.

Regards,

Andrew

On Wed, Oct 12, 2016 at 10:40 AM, Benjamin Armintor <armi...@gmail.com> wrote:

The semantic versioning proposal would be a healthy one, I think.

The scheduled release proposal I am less sympathetic to. Are we to just maintain a log of known issues, and move everyone to snapshot releases until the next release comes around? Can an advocate for that schedule identify another open source project that works that way?

- Ben

On Wed, Oct 12, 2016 at 10:31 AM, Mike Giarlo <mjgi...@stanford.edu> wrote:

David,

Part of a move to semantic versioning for Fedora would, IMO, necessitate a shift in branding away from "Fedora 4" and back towards "Fedora." (Same as it ever was...)

Andrew didn't propose that specifically, but I assume that's part of the package for the reason you mention. "Fedora4 8.1.2" should never be a thing. I suspect we can all agree on that. Maybe?

-- 
Michael J. Giarlo

Technical Manager, Hydra-in-a-Box project

Software Architect, Digital Library Systems & Services

Stanford University Libraries

From: fedor...@googlegroups.com <fedor...@googlegroups.com> on behalf of David Chandek-Stark <david.cha...@duke.edu>
Sent: Wednesday, October 12, 2016 07:18
To: Fedora Tech

Cc: fedora-community@googlegroups.com; hydra...@googlegroups.com; isla...@googlegroups.com; fedora-...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups "Fedora Leaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-leaders+unsubscribe@googlegroups.com.

[Adam Wead]

Andrew,

Thanks for bringing this up. +1 to sem. ver. As far as the schedule is concerned, I think we should release when we need to release, whether that be for bug fixes, changes in dependencies, or because we have rallied some community involvement for a particular feature. I haven't heard anything about there being a lack or regular releases, but maybe I just haven't been paying attention :)

Is the idea behind the schedule that it keeps us focused on doing new things?

Lastly, I'd like to second Mike G.'s comment that we just drop the "4" in "Fedora 4" and if there's a non-backwards compatible change or feature, it's now Fedora 5. This is what we've tried to do with Hydra's gems, and it's mostly been successful. The challenge, however, lies in being able to identify each change correctly.

…adam

On Oct 12, 2016, at 10:45 AM, Andrew Woods <awo...@duraspace.org> wrote:

Hello Ben,

In terms of bi-annual releases, that is somewhat arbitrary and is open for refinement. 

The point is that it would be helpful for community planning purposes to have scheduled and regular releases. If I have misheard the desire from the community to have scheduled and regular releases, that would be good to know.

Regards,

Andrew

On Wed, Oct 12, 2016 at 10:40 AM, Benjamin Armintor <armi...@gmail.com> wrote:

The semantic versioning proposal would be a healthy one, I think.

The scheduled release proposal I am less sympathetic to. Are we to just maintain a log of known issues, and move everyone to snapshot releases until the next release comes around? Can an advocate for that schedule identify another open source project that works that way?

- Ben

On Wed, Oct 12, 2016 at 10:31 AM, Mike Giarlo <mjgi...@stanford.edu> wrote:

David,

Part of a move to semantic versioning for Fedora would, IMO, necessitate a shift in branding away from "Fedora 4" and back towards "Fedora." (Same as it ever was...)

Andrew didn't propose that specifically, but I assume that's part of the package for the reason you mention. "Fedora4 8.1.2" should never be a thing. I suspect we can all agree on that. Maybe? <OutlookEmoji-😉.png>

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

[Jim Coble]

+1 to semantic versioning and to moving away from the “Fedora 4” branding to just “Fedora”.

In terms of release schedule, I would envision patch level releases as being as frequent as needed to deal with security and high impact bugs.  I could see functionality releases (minor level) as two or three times a year.  Major releases perhaps no more than once a year.

--Jim

 

--------------------------------------------

Jim Coble

Enterprise Services

Duke University Libraries

jim....@duke.edu

--

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at https://groups.google.com/group/fedora-tech.

For more options, visit https://groups.google.com/d/optout.

 

--
You received this message because you are subscribed to the Google Groups "Fedora Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-communi...@googlegroups.com.

[Jon Stroop]

+1 to semantic versioning, going back to "Fedora" (senza 4).

The scheduled release proposal I am less sympathetic to. Are we to just maintain a log of known issues, and move everyone to snapshot releases until the next release comes around? Can an advocate for that schedule identify another open source project that works that way?

I tend to agree, except that I think having a community-endorsed Fedora spec that is out in front of any implementation could help with this quite a bit. If it were agreed that MAJOR/breaking releases would be limited to once or twice a year, a spec would go a long way toward coordinating those changes and limiting the number of migrations required in order to keep up (and frankly, I think MAJOR changes should probably be once a year or less--more than that runs the risk of splintering the community, forcing support for legacy versions longer than we might like, and suggesting that the product or the spec is unstable).

Similarly, a spec that is out in front of implementation would help to better coordinate MINOR releases that might be optional or less painful at more regular intervals (say every four to six months). Patches should always be allowed as necessary, but only for bug fixes and security concerns, and (as SemVer says) shouldn't introduce features.

Important to note that all of this also offers an opportunity to be more explicit about which versions are supported and for how long.

You received this message because you are subscribed to the Google Groups "Fedora Leaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-leader...@googlegroups.com.

[Kevin Ford]

I fully support moving to standard semantic versioning.

I think there is much more to unpack with respect to releases, their
frequency, their schedules, and the motivation behind each release.

The thin document David pointed to talks about how "Presently, the
codebase is evolving and settling, and the Fedora community has not yet
fully transitioned to relying on any given 4.x release for production
installations. Once this transition takes place, the Fedora project will
institute a policy of continued support for previous major releases.
Such a policy is not yet in effect, but this will be revisited on the
date mentioned above."

There is an assumption that Fedora is not being used, or considered
seriously for production, which has in turn fostered a situation that
makes this a self-fulfilling prophecy. So long as very large changes
are taking place, I think it is very reasonable for adopters to be wary
of using Fedora in production. I say this with some experience, having
recently fried a 4.6 installation because it's not thread-safe and I
only successfully performed a back up of a 4.6 installation after
shutting Fedora down, stopping other components in the system, and
making changes to how Fedora runs.

At some point, the Fedora community needs to put its backing behind a
stable, production-ready release. I would expect that backing to come
with a promise of continued support for a set amount of time and an
expectation that (backwards compatible) critical bugs/patches be
implemented regardless of defined release schedule.

With respect to Andrew's email about a release schedule (designed to
elicit conversation), I have a couple of questions:

1) Assuming a biannual release schedule and given the rate of changes in
the Fedora base, there is a very good chance that the next few releases
would be backwards incompatible. With no mention of bug-fix/patch
releases, should I plan on performing a complete repository *migration*
every 6 months? That can be taxing.

2) Would I have to wait up to 6 months for a critical bug fix?

I think MAJOR releases should be planned in so far as possible and no
more than once a year. Not only are the changes greater, the amount of
work expected leading up to the release (documentation of new features,
documentation of migration strategies, etc) is much greater. Is there a
reason this should happen any more than once a year? Doing so more
often - with all that a major release entails - seems like making more work.

I think a good start for MINOR releases would be a quarterly schedule.

I don't see a reason bug/patch releases need be on a schedule. If a bug
is identified and corrected within 2 weeks of a scheduled MINOR release,
for example, it may be perfectly justifiable to bundle it with the MINOR
release. It may, however, be important enough to release ASAP.

Yours,
Kevin

> <https://groups.google.com/group/fedora-tech>.

>
> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fedora-tech...@googlegroups.com

> <mailto:fedora-tech...@googlegroups.com>.

> To post to this group, send email to fedor...@googlegroups.com

> <mailto:fedor...@googlegroups.com>.

[David Chandek-Stark]

If Fedora (4) were using semantic versioning, what would the current major version be?  Arguably it should be "0" unless/until the public API has stabilized.  I believe that sends the same message as "still settling" to which I previously referenced.

--D

On Wednesday, October 12, 2016 at 9:27:21 AM UTC-4, Andrew Woods wrote:

[David Chandek-Stark]

Re: the "Fedora 4" brand, how about moving to "FCRepo" (or something else) instead of back to Fedora?  I imagine this discussion is old, but I've never weighed in. :)

1. In the larger software world, "Fedora" is far more likely to mean https://getfedora.org/

2. According to the recent poll at http://www.tricider.com/brainstorming/3P7PS2SFgXB, only one respondent affirmed that Fedora still fits the original acronym.

3. "fcrepo" is already established in the Java package names, the GitHub repo, etc., not to mention http://fcrepo.org/.

--D

On Wednesday, October 12, 2016 at 9:27:21 AM UTC-4, Andrew Woods wrote:

[Joshua Westgard]

I'm on board with semantic versioning. I don't have strong feelings about the frequency of releases, but Jim Coble's proposal that patch releases could be 'as needed' makes a lot of sense to me. Minor version releases could be kept to no more than twice a year, and hopefully Major versions releases will be not very often at all once we get the API spec ironed out.

As for the FEDORA name, I'd be reluctant to abandon that in favor of fcrepo.  There is a valuable brand built on the name, poll results about the acronym notwithstanding, and once API-X is in place we will again have the "E".  Plus the repository predates Redhat's Fedora so they should get their tanks off our lawn not the other way around... ;-)

But by all means drop the '4' from the branding. It has been a useful distinction while it lasted because there was a significant (i.e. complete) break with the previous codebase, but as more and more folks get onto 4 this will become less important.

Josh

[Andrew Woods]

Hello All,

Thank you for the input and discussion.

There seems to be general agreement on the advantages of employing standard semantic versioning.

There will be two sides to determining whether a given release requires a MAJOR version increment:

1. The API changes

** Which, hopefully will be very infrequent once we get the API specification work finished and Fedora implementation aligned with it

2. The backend data needs upgrade/migration

** This can be very disruptive, and we want to minimize such occurrences (noting a data upgrade is going to be required with Fedora 4.7.0)

I would like to push for a concerted community effort in finishing the API specification and alignment of implementation in order to avoid a prolonged, continual series of MAJOR version

 releases due to incrementally changing of the API towards a slowly defined specification.

As for release frequency, there seems to be consensus on keeping MAJOR releases to no more than once a year. This is a strong incentive to collectively move the previously mentioned specification/implementation work forward quickly.

It sounds like a frequency between quarterly and biannually for MINOR releases is reasonable.

PATCH releases should come out as frequently as necessary to address critical bugs or security vulnerabilities.

I have not heard in this thread any voices advocating for regularly scheduled releases in support of upgrade planning and management, but we as a community may want to continue to reflect on that.

Thank you again for your feedback so far. Your message is clear. There will need to be some discussion and planning on the timing of making such procedural changes, but knowing your thoughts on the matter is extremely helpful.

Regards,

Andrew

[Andy Wagner]

It's great to see this topic brought up for broad discussion.

I am definitely in favour of semantic versioning, however, I'd like to raise some concerns about the coupling of the versioning issue with scheduled releases. Scheduled releases transform SemVer into CalVer [1], and in my mind defeats the purpose of SemVer.

A vibrant Fedora community, which I believe we have, should be able to release a new version, be it a minor or a patch when it deems it appropriate. Minor versions, which by their nature are backwards compatible should have no restriction on their release frequency. (I'd also argue for majors without a schedule but that's a different thread.)

Those who have time to participate in testing will do so, with or without a schedule. The recent moves to increased automated testing are an excellent move towards Fedora's ability to rapidly progress and one could chart a relatively straightforward and direct line to a near term goal of verification of new versions based on the autonomous running of a suite of tests.

I'm currently on vacation and sleep deprived, but I felt the need to chime in on this.
~Andy

[1] http://calver.org/

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/islandora.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/CADz%3D0U%3D_AZ%2BcXy6UPYEd79tRSjOXO7xgggca%2B-2cpOaALV4zsg%40mail.gmail.com.

[Andrew Woods]

Hello Andy,

Thanks for your thoughts, and thank you for sharpening the point on this discussion targeting Semantic Versioning and not Calendar Versioning. I do not think anyone here is advocating for Calendar Versioning.

The two topics (semantic versioning and release scheduling) were both included in this thread to establish a rounded suggestion of how releases may be managed going forward. I agree that there should be no coupling between the two concepts beyond potentially limiting the number of MAJOR releases per year.

Enjoy the vacation ;)

Andrew

You received this message because you are subscribed to the Google Groups "Fedora Leaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-leaders+unsubscribe@googlegroups.com.