On 10/09/15 09:49, Pavel Pisa wrote:
Hello Sebastian,
On Thursday 10 of September 2015 08:52:37 Sebastian Huber wrote:
On 28/07/15 09:48, Chris Johns wrote:
Either scheme fits pretty well with RTEMS release cycle I think.
Even if we can get down to one release per year, the numbers
won't grow terribly fast.
One release per year would be nice.
We may need more flexibility.
I just wanted to say, that the four years or so it took to release
RTEMS 4.11 was a bit long.
Yes I agree. I think Joel wants a 4.12 which is close to 4.11 but
stripped of various things we kept in 4.11.
Once we have 5.0 and waf, buildbot will decide when a release is ready.
When the feature set for the release is available and buildbot shows the
code is suitable it can be released. It might be months or just weeks.
We have the 4.11 release branch, but still no release. Independent of
that, we have to adjust the version of the master. Will this be 4.12.99
or 5.0.0?
If there is 4.12 planned then it should be 4.11.99.
Hm, yes.
As for 4.99 and 5.0, I am not big fan of today fashion
to have three or more major numbers per year as Firefox and Chrome
has. So if there is really significant API change then the major
version increase is appropriate but if there is not than to stay
with single one with minor up to 20 or 30 is reasonable.
On the other hand if minor should reach 50 or even 100 then
I am for major increase. May it be that rule to not go with
minor above 9 could be used.
But above is only my feeling. But rule that complete version increase
is monotonic in master branch and in release does not reach any
version in master is critical. I have code which builds (thanks to versions
macros) from 4.6 to 4.11.
There was some discussion about version numbers in this thread. See also:
https://devel.rtems.org/wiki/Developer/Release#RTEMSReleaseNumberingandNaming
"Version Numbering Scheme for GCC 5 and Up"
https://gcc.gnu.org/develop.html
In think we should simply use the same. This is more or less in line
with the proposal from Gedare:
https://lists.rtems.org/pipermail/devel/2015-July/012056.html
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
