umon3.0

[Ed Sutter]

If there's a way to do that with git, yea I'd like to do that.
I eventually realized with uMon that the version number in version.h was 
almost meaningless,
so I started referring to the SVN realease number.  I'd actually prefer 
that it
be embedded with the repo so that I can just let it do it.
I had originally had a 3-part version number...

MAJOR.MINOR.PORTINFO

MAJOR only changed once.
When to increment MINOR was flakey at best.
PORTINFO was just an incrementing value as the port changed but 
MAJOR/MINOR did not.

I'll go to any scheme you guys think is most efficient. It just can't 
clash with 1.0 or 2.0.
Ed

> Some questions:
> Do you plan to embed the version number within the repo? Or only on the release?
>
> Do you intend to call the development version the same as what the
> release will be? This can be confusing for users, if they grab a
> development head of 3.0 and then it is updated a few more times before
> the release. There are varying ways to approach this issue.
>
> Gedare
>
>
> On Tue, Jul 14, 2015 at 11:17 AM, Ed Sutter
> <ed.sutter at alcatel-lucent.com> wrote:
>> Anyone,
>> Any objections to starting this new uMon tree off as uMon3.0?
>> History disallows me from using any major number less than '3'.
>> Speak now or...  well, you know.
>>
>> Ed
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel