shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Proposal To Branch for 1.0 Today
Date Sat, 06 Dec 2008 05:34:27 GMT
Ok, Happy to change the version to SNAPSHOT, there are valid arguments  
on both sides and no perfect solution.
but to give others the chance to comment, I am going to leave this one  
to you.

BTW, I didn't just 'delete the designated release branch and create  
one at a random point', we all spent several days talking about it on  
list, and you must have read the message that said what was going to  
happen.... its what started this micro thread.

In future, perhaps someone else should do the branch.

On 5 Dec 2008, at 19:30, Henning P. Schmiedehausen wrote:

> Ian Boston <ieb@tfd.co.uk> writes:
>
>> On 5 Dec 2008, at 02:29, Henning P. Schmiedehausen wrote:
>
>>> Ian Boston <ieb@tfd.co.uk> writes:
>>>
>>>> Why?
>>>> To indicate the version that trunk is targeting.
>>>
>>> Because that assumes that this is the version the trunk is
>>> targetting. If you find out halfway through working, that this  
>>> should
>>> be "2.0.0-SNAPSHOT", then you need to change it.
>
>> my point exactly,
>> no branch was done,
>> and suddenly the direction of bleeding edge has changed
>> anyone binding to the 1.1-SNAPSHOT still gets what they expected as
>> its still deployed or in their local repo.
>
> Yes. They would expect that after doing "mvn clean install", their
> code will pick up the latest, greatest changes. That's why they live
> on the trunk.
>
> What I do is (and I assume that most people work this way):
>
> /work/myproject %                           (Hmmm. I need to update  
> Shindig)
> /work/myproject % pushd /work/shindig-trunk
> /work/shindig-trunk % svn -q update
> /work/shindig-trunk % mvn -q clean install  (Let's get coffee)
> /work/shindig-trunk % popd
> /work/myproject % mvn clean install         (That should do it and  
> pick up all the changes)
>
> and it does not. Because in your scenario, the POM version on the
> trunk suddently changed. And worse, my code still builds, so I have no
> way of *noticing* that these changed, unless I follow the commits.
>
>
>> It Does depend how long afterwards you realize that all the commits
>> were going somewhere else, but I would hope that any project wouldn't
>> perform this sort of random walk towards a release ? IMHO I dont  
>> think
>> Shindig is doing that.
>
> Hearing that from the person that just deleted the designated release
> trunk and created a new one from a random point on the trunk makes me
> shiver.
>
>    Ciao
>        Henning
>
> -- 
> Henning P. Schmiedehausen - Palo Alto, California, U.S.A.
> henning@schmiedehausen.org "We're Germans and we use Unix.
> henning@apache.org          That's a combination of two demographic  
> groups
>                            known to have no sense of humour  
> whatsoever."
>                               -- Hanno Mueller,  
> de.comp.os.unix.programming


Mime
View raw message