umon3.0

[Ed Sutter]

On 7/14/2015 1:11 PM, Joel Sherrill wrote:
>
>
> On 7/14/2015 10:51 AM, Ed Sutter wrote:
>> On 7/14/2015 11:45 AM, Gedare Bloom wrote:
>>> 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.
>> Sorry, didn't reply to this part of the question, cause I'm not really
>> sure what you mean.
>> If we can just have ONE number (even if it increments for every git
>> push), that works
>> for me.  In other words, whatever most accurately reflects the running
>> version
>> is best from my point of view.
>
> One option is that version.h can be generated based on the git hash
> and some base level major/minor scheme.
Right.  I do that with many internal projects (with svn).
At build time I just create svnrev.h based on the HEAD.
On the other hand, internal projects are less complex in that there aren't
typically multiple ports and cpus supported etc...  Usually if a change is
made, its something the user should have; its not optional.

>
>>>
>>> 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
>>
>