manual may need updating but I am not sure.
I think a unified method for controlling version numbers would be good.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 28/01/2022 15:28, Christian MAUDERER wrote:
So I think at the moment, the engineering manual is wrong. The release
branch will always have the number N.0.0 as long as we don't change the
release process.
I think the manual is right and the version on the RTEMS 5 release
branch is wrong.
Author: Christian Mauderer
Date: Wed May 26 09:39:13 2021 +0200
cpukit: Add description of release version numbers
The release version in the git sources doesn't change. Add a note why
that is the case.
---
cpukit/include/rtems/version.h | 21 +
1 file changed, 21
+0200
cpukit: Add description of release version numbers
The release version in the git sources doesn't change. Add a note why
that is the case.
---
cpukit/include/rtems/version.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/cpukit/include/rtems/version.h b/cpukit
Ok and thanks. :)
On 27/5/21 6:56 pm, Christian Mauderer wrote:
> The release version in the git sources doesn't change. Add a note why
> that is the case.
> ---
> v2: Integrate suggestions from Chris Johns.
>
> cpukit/include/rtems/version.h | 21 +
> 1 file changed, 21
The release version in the git sources doesn't change. Add a note why
that is the case.
---
v2: Integrate suggestions from Chris Johns.
cpukit/include/rtems/version.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/cpukit/include/rtems/version.h
Thank you for this.
On 26/5/21 7:41 pm, Christian Mauderer wrote:
> The release version in the git sources doesn't change. Add a note why
> that is the case.
> ---
> cpukit/include/rtems/version.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
The release version in the git sources doesn't change. Add a note why
that is the case.
---
cpukit/include/rtems/version.h | 12
1 file changed, 12 insertions(+)
diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h
index a8aff732f3..2e068cd976 100644
---
+1
On 2/2/21 7:51 am, Gedare Bloom wrote:
> ---
> user/start/gsoc.rst | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
> index 7f27d7b..f8167b9 100644
> --- a/user/start/gsoc.rst
> +++ b/user/start/gsoc.rst
> @@ -20,6 +20,12 @@ delving
---
user/start/gsoc.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
index 7f27d7b..f8167b9 100644
--- a/user/start/gsoc.rst
+++ b/user/start/gsoc.rst
@@ -20,6 +20,12 @@ delving into the details. For more information you can go
through the
I pushed this.
On Wed, Apr 1, 2020 at 9:35 PM Gedare Bloom wrote:
>
> Closes #2562.
> ---
> user/start/preparation.rst | 49 ++
> 1 file changed, 49 insertions(+)
>
> diff --git a/user/start/preparation.rst b/user/start/preparation.rst
> index
Closes #2562.
---
user/start/preparation.rst | 49 ++
1 file changed, 49 insertions(+)
diff --git a/user/start/preparation.rst b/user/start/preparation.rst
index 546a03d..eb0d56b 100644
--- a/user/start/preparation.rst
+++ b/user/start/preparation.rst
@@ -1,8
From: Chris Johns
---
common/conf.py| 15 ---
common/version.py | 25 -
common/waf.py | 5 -
wscript | 3 +++
4 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/common/conf.py b/common/conf.py
index fe44640..97f8dfa 100644
On 5/01/2016 5:03 PM, Sebastian Huber wrote:
>
> I used the versions of the contrib/download_prerequisites script of the
> GCC.
The page https://gcc.gnu.org/install/prerequisites.html indicates later
versions can be used. I cannot remember the reason these are selected.
It may have been
On 05/01/16 09:45, Chris Johns wrote:
On 5/01/2016 5:03 PM, Sebastian Huber wrote:
>
>I used the versions of the contrib/download_prerequisites script of the
>GCC.
The pagehttps://gcc.gnu.org/install/prerequisites.html indicates later
versions can be used. I cannot remember the reason these
On 5/01/2016 7:48 PM, Sebastian Huber wrote:
> On 05/01/16 09:45, Chris Johns wrote:
>> On 5/01/2016 5:03 PM, Sebastian Huber wrote:
>>> >
>>> >I used the versions of the contrib/download_prerequisites script of the
>>> >GCC.
>> The pagehttps://gcc.gnu.org/install/prerequisites.html indicates
Hello Chris,
I used the versions of the contrib/download_prerequisites script of the GCC.
On 05/01/16 00:23, Chris Johns wrote:
Hi Sebastian,
Looking at 4.12 build in the RSB I see:
mpfr2.4.2
mpc0.8.1
gmp4.3.2
The 4.11 gcc-4.9.3 is using:
mpfr3.0.1
mpc
Hi Sebastian,
Looking at 4.12 build in the RSB I see:
mpfr 2.4.2
mpc0.8.1
gmp4.3.2
The 4.11 gcc-4.9.3 is using:
mpfr 3.0.1
mpc0.8.2
gmp5.0.5
4.12/rtems-arm builds on FreeBSD.
Ok to update to the 4.11 versions?
Chris
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.
>
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
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
n 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/Develop
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 6.3, 6.5, etc as bug fix.
The advantage of this scheme is that all development versions have a
clear label. The question boils down to do we care to provide
development version numbers of maintenance branches?
I am fine with this scheme. So, there is basically a single Y.ODD commit
to do we care to provide
development version numbers of maintenance branches?
I am fine with this scheme. So, there is basically a single Y.ODD commit for
the release, and then a Y.ODD+1 commit to change the number for the next
development cycle. I think its nice if we can go from three numbers
branch, and 5.3 as the bugfix release.
6.0 is development version after 5.0.
6.1 next release, with 6.3, 6.5, etc as bug fix.
The advantage of this scheme is that all development versions have a
clear label. The question boils down to do we care to provide
development version numbers
Hello,
shortly before I go on holiday, I thought it is a good time to start a
discussion about version numbers. GCC recently changed their version number
scheme and it might be something that fits also quite good for RTEMS. The
major releases are indicated by the left-most number followed
have a
clear label. The question boils down to do we care to provide
development version numbers of maintenance branches?
I am fine with this scheme. So, there is basically a single Y.ODD commit for
the release, and then a Y.ODD+1 commit to change the number for the next
development cycle
.
The advantage of this scheme is that all development versions have a
clear label. The question boils down to do we care to provide
development version numbers of maintenance branches?
I am fine with this scheme. So, there is basically a single Y.ODD commit
for the release
29 matches
Mail list logo
