Re: Stable release of mc-4.7.0.3
- From: Slava Zanko <slavazanko gmail com>
- To: Oswald Buddenhagen <ossi kde org>, mc devel <mc-devel gnome org>
- Subject: Re: Stable release of mc-4.7.0.3
- Date: Sat, 27 Feb 2010 02:05:07 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
27.02.2010 01:20, Oswald Buddenhagen wrote:
>> [epoch].[major].[minor].[release]
> that's pretty much a guarantee that the epoch will never change.
Well... like in Linux kernel.
>> Also, they say that Redhat uses the same versioning scheme for the
>> kernels they support.
> the linux kernel's versioning scheme is an expression of a two-level
> generational development model. you may have noticed that this was
> dropped years ago - the major version is fixed at 2.6. and you never had
> such a model in the first place, and you'll never have. so why would you
> introduce such a scheme?
- mc-4.7 like to kernel-2.6
- mc-4.7.1 like to kernel-2.6.33
- mc-4.7.0.* like to kernel-2.6.18-* (CentOS/RHEL based versioning)
So mc-4.7.0.* (stable branch) have two part of versioning:
mc-[4.7.0].[*]
First part is needed for indicate 'forked as stable' version. Second
part is needed for indicate 'patch level' version. In future we will
release out 4.8.0 (in master). And stable branch will change a 'base' -
new stable fork will have '4.8.0' tag as start point, and versioning
will repeated: 4.8.0.* (for stable branch) and 4.8.* (for master branch).
http://www.midnight-commander.org/wiki/ReleaseWorkflow (if you mean that
page contain poor info - keep your comments and proposals here)
About first 'epoch'. If project will have too much ideas (such as
totally rewritten on C++ or mono ;) ), then we will change epoch (joke).
If seriously, I think first number will changed after huge changes in
project. For example, after additions of plugins (*.so) for 'panels',
'editor' or 'viewer' components... this is just example, not a milestone
:). Or after similar changes...
>> Other than that, it's a matter of subjective preferences, I guess.
> yes, one can also prefer a versioning scheme which converges towards the
> value of pi. this isn't necessarily sane or even useful, though.
No, don't need for 'pi' :) I hope, now you have more understanding about
versioning scheme... and your proposal(if there) always welcome.
- --
WBR, Slavaz.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkuIYasACgkQb3oGR6aVLpr4NQCeP0izMLcAqbT/ziNS6qTRVaPq
OBsAnisWOmU9sffR00+BhlZuzoZ0Oa2R
=ucRS
-----END PGP SIGNATURE-----
[
Date Prev][Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]