Ok, we need to figure how this works together with all the auto-mirrors
around (github/asf/maven, etc).
Are we d'accord that we must _not_ do releases on master but always
create
a temporary branch for each release (and then merge back to master after
the vote passed) ?
LieGrue,
strub
----- Original Message -----
> From: Kristian Rosenvold <[email protected]>
> To: Maven Developers List <[email protected]>
> Cc:
> Sent: Friday, September 21, 2012 10:33 AM
> Subject: Re: Scm, Surefire, Wagon migrate to git (please check) [was
Plan for git migration]
>
> You don't really "crash" anything, but if the tag is rewritten you
> have to delete the local tag to actually get the updated reference to
> the tag.
>
> The authorative repo is correct, but there may be some clones out
> there that are unaware of the failed release and the moved tag.
>
> I still think the benefit of moving the tag > just tagging locally
> (and hence missing tags).
>
> Could we introduce something like subtagging ? If the official release
> tag is "xyz_plugin_1.2.3", could we have the release plugin tag the
> first version as "xyz_plugin_1.2.3_0" and just automatically advance
> the tag for each re-release ? Then we *could* have some automated step
> in the post-vote process burniung the final release number based on
> highest available subtag (and delete the subtags) ?
>
> I suppose a similar post-vote tool could also just push the local
> release tag to the repo, so I may be complicating things.....?
>
> Kristian
>
>
>
>
>
>
>
>
>
>
>
> 2012/9/20 Mark Struberg <[email protected]>:
>> Hi folks!
>>
>> The problem is the rollback.
>> In DeltaSpike we do _not_ push now. deleting a tag on one repo is
not a
> problem, but you would crash all downstream clones as re-trying a
release is
> basically a history rewrite.
>>
>> In DeltaSpike I do the release locally and push the tag + release
branch to
> my github clone (or any other public repo you like).
>> After the VOTE passes I merge it to master and push it to the ASF
canonical
> repo.
>>
>> Not perfect neither, but worked far better than history rewrites at
least
> ;)
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Kristian Rosenvold <[email protected]>
>>> To: Maven Developers List <[email protected]>
>>> Cc:
>>> Sent: Thursday, September 20, 2012 4:56 PM
>>> Subject: Re: Scm, Surefire, Wagon migrate to git (please check)
[was
> Plan for git migration]
>>>
>>> I just checked and there is no general blocking for deleting tags.
We
>>> should definitely push as part of release plugin. Tags ar cheap.
>>>
>>> Kristian
>>>
>>>
>>> 2012/9/20 Olivier Lamy <[email protected]>:
>>>> 2012/9/20 Mark Derricutt <[email protected]>:
>>>>> Olivier,
>>>>>
>>>>> I'm not checked yet ( not thru lazyness, but thru
> buzyness, and
>>> shooting this email just as I think of it ), in all my local
maven/git
> projects
>>> I set in the maven-release-plugin configuration:
>>>>>
>>>>> <pushChanges>false</pushChanges>
>>>>> <localCheckout>true</localCheckout>
>>>>>
>>>>> to prevent any upstream/origin pushes during release ( there
> may not BE
>>> an origin/remote yet ). There was some discussion either on here,
or
in
> JIRA (
>>> not sure off hand which ) about making these options the default
for
> any of the
>>> supported distributed version control systems.
>>>>>
>>>>> Does anyone know if this was done? Should these options be
> mandated as
>>> a standard practise for maven+git conversion?
>>>>
>>>> No release yet.
>>>> But regarding <pushChanges>false</pushChanges>, I
> remember we
>>> used on
>>>> jenkins side and everybody missed the manual step (push the tag)
> when
>>>> released. So we moved to true.
>>>> BTW it's something to discuss.
>>>> Maybe pushing the tag once release vote passed ?
>>>> I remember some discussions on ASF infra for blocking of tag
> deletion
>>>> (I don't know if this has been applied on the final infra)
> because we
>>>> sometimes delete tags if the release vote fail.
>>>> I can test creating a fake tag and try delete it :-)
>>>>
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>> On 20/09/2012, at 1:40 AM, Olivier Lamy
> <[email protected]> wrote:
>>>>>
>>>>>> BTW I have started a page here:
>>>>>> http://maven.apache.org/developers/conventions/git.html
>>>>>>
>>>>>> we could put some git tips and more conventions.
>>>>>>
>>>>>>
>>>>>> 2012/9/18 Arnaud Héritier <[email protected]>:
>>>>>>> My remarks about these repos :
>>>>>>> * trunk will have to be renamed master (I'm not
> sure if
>>> we'll go further
>>>>>>> like using the git workflow with the develop branch to
> keep
>>> master as
>>>>>>> stable as possible - In any case I would recommand to
> follow a
>>> convention
>>>>>>> fix/XXXX, stable/A.B.C, feature/ZZZZ to organize
> branches)
>>>>>>> * A strange thing I didn't have in my company
> repositories
>>> I recently
>>>>>>> migrated is the commit/tag (copy for tag) for each
> release done
>>> by the
>>>>>>> release plugin. I don't know if it is a different
> setting
>>> in the plugin or
>>>>>>> something cleaned by filters I applied in the SVN
> -> GIT
>>> migration we did
>>>>>>> * Some strange branches to cleanup ? ASF, APACHE or by
> user
>>> (trygvis,
>>>>>>> evenisse ...)
>>>>>>>
>>>>>>> That's all what I see for now.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 18, 2012 at 8:29 PM, Arnaud Héritier
>>> <[email protected]>wrote:
>>>>>>>
>>>>>>>> I Will test them. Will they keep these ugly URLs
> git-wip-us
>>> in the
>>>>>>>> future ? I'm not a fanatic but I would prefer
> to have
>>> something stable
>>>>>>>> to put in our POMs for releases. I know that we
> don't
>>> use often scm
>>>>>>>> infos after the release but it is sad if we know
> that
>>> they'll be
>>>>>>>> discontinued in a near future. No ?
>>>>>>>>
>>>>>>>> Le 18 sept. 2012 à 19:23, Olivier Lamy
>>> <[email protected]> a écrit :
>>>>>>>>
>>>>>>>>> Repositories has been migrated to:
>>>>>>>>> *
>>> https://git-wip-us.apache.org/repos/asf/maven-surefire.git
>>>>>>>>> *
>>> https://git-wip-us.apache.org/repos/asf/maven-wagon.git
>>>>>>>>> *
> https://git-wip-us.apache.org/repos/asf/maven-scm.git
>>>>>>>>> They are currently read only.
>>>>>>>>> Content looks good.
>>>>>>>>> If nobody complains, I will ask to move to rw
> mode
>>> tomorrow. (in 24H)
>>>>>>>>>
>>>>>>>>> 2012/9/18 Olivier Lamy
> <[email protected]>:
>>>>>>>>>> Hi
>>>>>>>>>> See
>>> https://issues.apache.org/jira/browse/INFRA-5266
>>>>>>>>>> Those tree svn paths will be readonly now
> for
>>> migration.
>>>>>>>>>>
>>>>>>>>>> 2012/9/12 Olivier Lamy
> <[email protected]>:
>>>>>>>>>>> Hi Folks,
>>>>>>>>>>> So the vote passed, now it's time
> for
>>> volunteers to use their fingers
>>>>>>>> :-).
>>>>>>>>>>> I have started a page [1] for ETA of
> migration
>>> (note the Volunteer
>>>>>>>>>>> column :-) ) and for discussion on
> some stuff
>>> (plugins shared)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> --
>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>> http://twitter.com/olamy |
>>> http://linkedin.com/in/olamy
>>>>>>>>>>> [1]
>>> https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Olivier Lamy
>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>> http://twitter.com/olamy |
>>> http://linkedin.com/in/olamy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Olivier Lamy
>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>> http://twitter.com/olamy |
> http://linkedin.com/in/olamy
>>>>>>>>>
>>>>>>>>>
>>>
---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail:
>>> [email protected]
>>>>>>>>> For additional commands, e-mail:
>>> [email protected]
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -----
>>>>>>> Arnaud Héritier
>>>>>>> 06-89-76-64-24
>>>>>>> http://aheritier.net
>>>>>>> Mail/GTalk: [email protected]
>>>>>>> Twitter/Skype : aheritier
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>
>>>>>>
>>>
---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>
>>>>>
>>>>>
> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
