On Tuesday, June 24, 2014 04:55:33 AM Jan Lieskovsky wrote:
Hello folks,
since the request to give more formalized shape to SSG release process /
schedule appeared couple of times in the past already (to mention some
example:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-May/00541
6.html)
I think a faster release cadence is a good idea in general. But beside
speeding it up, some more formalities need to be considered. The biggest one
is what is the meaning of major, minor, and patch in the project versioning?
When would there be a stable branch?
Then, based on having a versioning policy, its desirable to overlay that with
goals. What are the goals for 0.2? 0.3? 1.0?
As the project grows in importance, these need to be documented so that
consumers know what to expect.
-Steve
and since we are hitting the doubt if already make / not to make yet
a new
release each time (each couple of weeks), we have decided to share the idea
about SSG release process proposal.
The proposal is to have release of new tarballs to happen at regular time
(each 4 up to 6 weeks), and have a dedicated wiki page listing when the
couple of upcoming releases will happen [1]. Something like Mozilla is
doing for their products:
https://wiki.mozilla.org/Releases
https://wiki.mozilla.org/Releases#Upcoming_Releases
https://wiki.mozilla.org/RapidRelease/Calendar
From the observation period of 6 weeks is enough to have "sufficient count
of new bug fixes / features requests" (aka the evolution step) these
changes by themselves to form a need of a new release. But since it's
difficult to decide if some patchset deserves new release (what's very
valuable for someone, might not be that exciting / urgent for someone else
etc.) to be fair we decided regular release period might be the best option
how to balance out the various requests that might come out.
Therefore starting from the next release we would like the release to
happen regularly (each 4 up to 6 weeks - this to be decided yet. Feel free
to vote for your preferences) at a date listed on the wiki page [2]. This
could allow us establish automated functionality which could in
sufficiently ahead period of time (for example week ago) notify the list
the new release is coming and if someone is planning from their point of
view critical patches to be included yet, those should be proposed /
reviewed as soon as possible.
To express personal opinion I would prefer the releases to happen on per 4
week scenario (while 6 weeks window might produce more changes in the
tarball & less releases during the year at the end it also introduces some
related inconsistency - one time the release would happen at start of the
month, next time in the middle etc.) since it has the advantage the release
will happen each time at regular (same) period, so users can update their
functionality to better align upgrades with the schedule.
Yet, since majority of us works on various / multiple projects, it might
happen start of the week might not be the right time for new release
(urgent action required somewhere else resulting into delay of a release
etc.). Therefore I would propose the release to happen each first Friday in
the month (the users could use the upcoming weekend to install the updates
if / where appropriate).
Feedback, comments, votes, proposals welcome.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team (on behalf of SSG
upstream)
[1] For now the wiki would contain just dates of past releases & dates of
the upcoming ones (possibly also describing the release scheme). In the
future it could provide further information what functionality each of the
releases introduced (and taking it to the very advanced level hopefully too
which functionality the new releases will contain in the future).
[2] Once the scheme is clear (the proposal is approved), I will create that
wiki page. _______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide