gedare at gwu.edu
Tue Jul 14 15:56:51 UTC 2015
We're planning to use a scheme in which the minor number denotes
development versus release. I think even numbered minors will be for
development, but I'd have to double-check.
On Tue, Jul 14, 2015 at 11:47 AM, Ed Sutter
<ed.sutter at alcatel-lucent.com> wrote:
> 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
> 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
>> 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
> umon-devel mailing list
> umon-devel at rtems.org
More information about the umon-devel