VERSION change

[Joel Sherrill]

On 4/23/2013 2:21 AM, Sebastian Huber wrote:
> Hello,
>
> I think this is a good idea.  We may also use some sort of the old Linux
> version scheme, e.g. use .even as the development version and use .odd as a
> release snapshot.
I don't care what we do but one thought I had overnight is that a
"real release" version number shouldn't match more than more
git hash.

The use of the "next major" version in the tools and keeping the
code stamped "current major" while we are in between is confusing.

The tool target being "next major" was to avoid a tool respin at branch
time. I don't know if this is a factor or not. Technically changing the 
target
name when we branch impacts the tool stability. It is easy enough to
argue that we are just renaming and it has no real impact though. But it
is a thought.

The RTEMS Major and Minor macros need to be testable in code. They
must be numeric and increasing.

We just need a pattern that makes sense. :)

--joel

On 04/22/2013 10:51 PM, Gedare Bloom wrote:
>> Hi,
>>
>> I would like to propose we change the version numbering system for the
>> development (and release branches) to represent the next pending
>> release number for that branch. So VERSION would contain, for the
>> following branches:
>> master -> 4.11.0
>> 4.10 -> 4.10.3
>> 4.9 -> 4.9.7
>> 4.8 -> 4.8.3
>>
>> This will simplify a number of release-related procedures, as well as
>> make the master tool versions align with the VERSION information.
>> Hopefully it will also reduce user confusion.
>>
>> Register any complaints or cheers here.
>>
>> -Gedare
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985