maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <kristian.rosenv...@gmail.com>
Subject Re: Scm, Surefire, Wagon migrate to git (please check) [was Plan for git migration]
Date Fri, 21 Sep 2012 11:40:56 GMT
> 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) ?

Now it's getting interesting:

git clone git://git.apache.org/maven-surefire.git
cd maven-surefire
gitk --all &

git clone https://github.com/sonatype/plexus-utils.git
cd plexus-utils
gitk --all &


Hold the two gitk windows side by side;)

Now the tags in surefire seem like the textbook way to do this,
whereas plexus-utils has ugly tags. But is there any way to have
release-plugin actually *make* tags like surefire has ? (these are
from the asf git clone, so they have been created by some dark
magics...)

Kristian




>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Kristian Rosenvold <kristian.rosenvold@gmail.com>
>> To: Maven Developers List <dev@maven.apache.org>
>> 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 <struberg@yahoo.de>:
>>>  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 <kristian.rosenvold@gmail.com>
>>>>  To: Maven Developers List <dev@maven.apache.org>
>>>>  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 <olamy@apache.org>:
>>>>>   2012/9/20 Mark Derricutt <mark@talios.com>:
>>>>>>   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
>> <olamy@apache.org> 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 <aheritier@gmail.com>:
>>>>>>>>   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
>>>>  <aheritier@gmail.com>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
>>>>  <olamy@apache.org> 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
>> <olamy@apache.org>:
>>>>>>>>>>>   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
>> <olamy@apache.org>:
>>>>>>>>>>>>   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:
>>>>  dev-unsubscribe@maven.apache.org
>>>>>>>>>>   For additional commands, e-mail:
>>>>  dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   --
>>>>>>>>   -----
>>>>>>>>   Arnaud Héritier
>>>>>>>>   06-89-76-64-24
>>>>>>>>   http://aheritier.net
>>>>>>>>   Mail/GTalk: aheritier@gmail.com
>>>>>>>>   Twitter/Skype : aheritier
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   --
>>>>>>>   Olivier Lamy
>>>>>>>   Talend: http://coders.talend.com
>>>>>>>   http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>
>>>>>>>
>>>>  ---------------------------------------------------------------------
>>>>>>>   To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>   For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>   To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>   For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   --
>>>>>   Olivier Lamy
>>>>>   Talend: http://coders.talend.com
>>>>>   http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>>   To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>   For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>  ---------------------------------------------------------------------
>>>>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>  For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>  For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message