[Vm-dev] VM Maker: VMMaker-oscog.52.mcz

Igor Stasenko siguctua at gmail.com
Sun Mar 20 21:02:05 UTC 2011


On 20 March 2011 20:33, Matthew Fulmer <tapplek at gmail.com> wrote:
>
> On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote:
>> Except that its my branch and I've been using oscog from the start.  Igor
>> had no need to use the same name line as me.  I don't want to change now.
>>  oscog refers to my branch of VMMaker for "open source Cog".
>
> It's not really open source if nobody else can contribute to
> that branch. Squeaksource apparently allows versions to be
> overwritten. I didn't know that either. Maybe that's part of the
> reason the naming convention has been adopted:
> Package-author.version
>
> The best supported convention for maintaining a branch is to use
> a different repository. MC is distributed, so packages can be
> merged between repositories no problem.
>
> So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz
> would be a trunk commit, and
> http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would
> be a cog commit.
>
> Changing the package name is not really supported; Most MC
> implementations can't merge between packages (MC1.5 could, but I
> havn't ported that to any MC that's actually in use)
>
> I like seperate repositories better anyway; then you can know if
> there is a newer version of your branch available just by seeing
> if VMMaker package is bold in the repo browser; if they are in
> the same repository, you have to pay attention to the commits
>

I agree that having different repos could simplify things.
Except things which will otherwise complicate them:
 - publishing new VMMaker version sends nice email to mailing list
 - configuration(s) to automatically load VMMaker with all
dependencies relying on having VMMaker package at certain known
location,
not at multiple ones.

So, lets keep pushing to SqS/VMMaker but use different naming scheme.


> --
> Matthew Fulmer (a.k.a. Tapple)
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list