[Proj] Confused by git branch management

Charles Karney charles.karney at sri.com
Wed Aug 26 19:41:27 EST 2015


One of the reasons that the previous update (4.8.0 to 4.9.1) was so
difficult was that the time between these releases was so long (about 3
years).  Coming out with releases every six months or year should not be
traumatic.  If it is, then there are other problem with the way the
releases are managed or with how dependent libraries find proj; and we
should address these.

   --Charles

On 08/26/2015 08:09 PM, support at mnspoint.com wrote:
> Hello,
>
> if there is only some very minor work done ... please DO NOT generate
> new versions since lot of people have to do lot of update work!!
>
> Even I think 4.9 was already out .. so that will go to the next one?!
>
> Thank You!
>
> Janne.
>
> ----------------------------------------------------------
>
>
> Even Rouault kirjoitti 25.08.2015 18:46:
>> Hi,
>>
>> I've just pushed a fix to trunk and branch/4.9, the latest I assumed to
>> be the
>> one that would gave a proj 4.9.2, but when digging more, it appears
>> this
>> branch/4.9 is really outdated
>> (https://github.com/OSGeo/proj.4/commits/4.9).
>> It looks like it is basically 4.9.0 plus a couple of fixes I committed
>> afterwards.
>>
>> I'm wondering if it wouldn't be appropriate to :
>> 1) kill this branch/4.9
>> 2) copy tag/4.9.1 as branch/4.9 (or from the master commit that
>> corresponds)
>> 3) and reapply on top of the relevant commits
>>
>> I guess this would translate to
>> 1) git push origin :4.9
>> 2) git checkout tag/4.9.1
>>      git branch -b 4.9
>>      git push origin 4.9
>> 3) git cherry-pick ...
>>
>> But my git abilities are limited, so advice would be welcome, in case
>> we agree
>> this is the right strategy.
>>
>> Even
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



More information about the Proj mailing list