ed.sutter at alcatel-lucent.com
Tue Jul 14 19:27:24 UTC 2015
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
>> 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.
>>> 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