Fedora Release Schedule and Semantic Versioning

33 views
Skip to first unread message

Andrew Woods

unread,
Oct 12, 2016, 9:27:23 AM10/12/16
to fedor...@googlegroups.com, fedora-community, Hydra-Tech, islandora, fedora-...@googlegroups.com
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

Andrew Woods

unread,
Oct 12, 2016, 10:26:18 AM10/12/16
to fedor...@googlegroups.com, fedora-community, Hydra-Tech, islandora, fedora-...@googlegroups.com
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

On Wed, Oct 12, 2016 at 10:18 AM, David Chandek-Stark <david.cha...@duke.edu> wrote:
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

--
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.

Andrew Woods

unread,
Oct 12, 2016, 10:45:41 AM10/12/16
to fedora-...@googlegroups.com, hydra-tech, Fedora Tech, fedora-c...@googlegroups.com, isla...@googlegroups.com
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
Subject: [fedora-tech] Re: Fedora Release Schedule and Semantic Versioning
 
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

On Wednesday, October 12, 2016 at 9:27:21 AM UTC-4, Andrew Woods wrote:
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.

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

--
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.

Andrew Woods

unread,
Oct 13, 2016, 11:10:34 PM10/13/16
to fedor...@googlegroups.com, fedora-community, Hydra-Tech, islandora, fedora-...@googlegroups.com
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

unread,
Oct 14, 2016, 5:43:29 AM10/14/16
to isla...@googlegroups.com, fedora-...@googlegroups.com, Hydra-Tech, fedora-community, fedor...@googlegroups.com

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

unread,
Oct 14, 2016, 11:50:39 AM10/14/16
to fedora-...@googlegroups.com, islandora, Hydra-Tech, fedora-community, fedor...@googlegroups.com
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.
Reply all
Reply to author
Forward
0 new messages