umon3.0

[Gedare Bloom]

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.

-Gedare

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
> 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
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel