[squeak-dev] Inbox and Communication

Levente Uzonyi leves at elte.hu
Sun Apr 17 16:44:36 UTC 2011


On Sun, 17 Apr 2011, Hannes Hirzel wrote:

> On 4/16/11, Chris Muller <asqueaker at gmail.com> wrote:
>> Interesting naming scheme; is that something we should "document" in
>> MCVersionName?
>
> Yes, please

The question was not about if there should be some documentation added or 
not, but whether if this naming convetion is/should be widely used. 
There's at least one other existing naming scheme for branches 
(http://wiki.squeak.org/squeak/3328 ), but IIRC we used to use something 
for Gjallar too.
So IMHO if it's added to the class comment, then it should only be a 
suggestion for future users.


Levente

>
> --Hannes
>
>>
>> Also, just to clarify our words, MC _does_ support branches in the
>> domain, just not names for them.  But in terms of the ancestry, you
>> can unlimited branching, which could be rendered if the tools were
>> improved to do that..  Adding a name to something can often be done
>> via external annotation, notwithstanding this naming scheme..
>>
>>
>> On Sat, Apr 16, 2011 at 11:37 AM, Colin Putney <colin at wiresong.com> wrote:
>>> On Fri, Apr 15, 2011 at 10:57 PM, Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>>
>>>> Use some false initials that name the branch, and start its version
>>>> numbers
>>>> from e.g. 1.  So I name my open-source Cog versions VMMaker-oscog.N.  The
>>>> package still has my initials as author.  David is using
>>>> VMMaker-oscog.dtl.N, etc.
>>>
>>> Actually, MC does have some support for branching. If you use the
>>> following convention, MC will do the "right" thing - group the
>>> branched versions together in the UI, automatically suggest a version
>>> name that's on a branch, and still allow you to merge between
>>> branches. The naming convention is:
>>>
>>> <package>.<branch>-<initials>.<id>
>>>
>>> So if Eliot were using the standard convention, his versions would be
>>> named like this:
>>>
>>> VMMaker.oscog-eem.147
>>>
>>> Colin
>>>
>>>
>>
>>
>
>



More information about the Squeak-dev mailing list