ed.sutter at alcatel-lucent.com
Tue Jul 14 15:47:46 UTC 2015
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
so I started referring to the SVN realease number. I'd actually prefer
be embedded with the repo so that I can just let it do it.
I had originally had a 3-part version number...
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.
> 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.
> On Tue, Jul 14, 2015 at 11:17 AM, Ed Sutter
> <ed.sutter at alcatel-lucent.com> wrote:
>> 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.
>> umon-devel mailing list
>> umon-devel at rtems.org
More information about the umon-devel