grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB version numbering.


From: Daniel Kiper
Subject: Re: GRUB version numbering.
Date: Wed, 27 Mar 2019 14:44:12 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Mar 26, 2019 at 11:32:36AM -0500, Bruce Dubbs wrote:
> I have been following the grub-devel list for many years.  It is my
> understanding that release of the next stable version of GRUB is imminent.
>
> That is great.  grub-1.99 was in 2011, grub-2.00 in 2012, and grub-2.02 in
> 2017.
>
> May I suggest that the number of changes introduced in the last two years
> indicate a more substantive number bump.  Generally most open source
> packages have a numbering scheme in the form of major.minor.patch.
>
> Would the changes introduced be sufficient to create the next stable version
> to be 3.0.0?  Or perhaps 2.1.0?  This would provide users an indication of
> the scope of the change just by looking at the version number. It would also
> encourage more rapid releases as new functionality is put into the package
> or bugs are fixed.

We have chatted among maintainers about that some time ago but finally
stated that change in versioning scheme may create more confusion than
it is worth of it. So, I can confirm more or less what Colin said: we
are not going to change versioning schema in the foreseeable future.

> Don't get me wrong.  Packages can release too frequently from my
> perspective.  Indeed, the Linux kernel outputs about two 'stable' releases a
> week.  That is hardly 'stable'.  For a package like GRUB, a release every
> six months on a schedule would be ideal, but that may not be best for this
> package.

We have chatted with many people about GRUB release frequency during
last FOSDEM. We are aware that we have to improve the release process
and probably change release cadence. However, this is not our top
priority for now. We are focusing on the release. Though I can promise
that we came back to the discussion and update the release process
accordingly.

> In any case, I appreciate and consideration you may give to this proposal.

Thank you for your input.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]