You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by sebb <se...@gmail.com> on 2013/07/17 14:21:37 UTC
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
On 17 July 2013 10:56, <el...@apache.org> wrote:
> Updated Branches:
> refs/heads/trunk 0d04eba45 -> 84b2003fc
>
>
> Revert "[maven-release-plugin] prepare for next development iteration"
>
> This reverts commit 0d04eba4525ca85886c4a03acc20b444ff69a52d.
However trunk is now in an incorrect state, as all the versions are
missing the -SNAPSHOT suffix.
Surely there is a release plugin goal to restore trunk to its original state?
maybe release:rollback ?
>
> Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> Commit: http://git-wip-us.apache.org/repos/asf/mina/commit/84b2003f
> Tree: http://git-wip-us.apache.org/repos/asf/mina/tree/84b2003f
> Diff: http://git-wip-us.apache.org/repos/asf/mina/diff/84b2003f
>
> Branch: refs/heads/trunk
> Commit: 84b2003fcd58c3938b2f218e11def87114775b78
> Parents: 0d04eba
> Author: Emmanuel Lécharny <el...@apache.org>
> Authored: Wed Jul 17 11:56:38 2013 +0200
> Committer: Emmanuel Lécharny <el...@apache.org>
> Committed: Wed Jul 17 11:56:38 2013 +0200
>
> ----------------------------------------------------------------------
> coap/pom.xml | 2 +-
> codec/pom.xml | 2 +-
> core/pom.xml | 2 +-
> distribution/pom.xml | 2 +-
> examples/pom.xml | 2 +-
> http/pom.xml | 2 +-
> pom.xml | 2 +-
> protobuf/pom.xml | 2 +-
> thrift/pom.xml | 2 +-
> 9 files changed, 9 insertions(+), 9 deletions(-)
> ----------------------------------------------------------------------
>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/coap/pom.xml
> ----------------------------------------------------------------------
> diff --git a/coap/pom.xml b/coap/pom.xml
> index bc39cea..0947c45 100644
> --- a/coap/pom.xml
> +++ b/coap/pom.xml
> @@ -24,7 +24,7 @@
> <parent>
> <groupId>org.apache.mina</groupId>
> <artifactId>mina-parent</artifactId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>mina-coap</artifactId>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/codec/pom.xml
> ----------------------------------------------------------------------
> diff --git a/codec/pom.xml b/codec/pom.xml
> index 3eead83..2e3c497 100644
> --- a/codec/pom.xml
> +++ b/codec/pom.xml
> @@ -23,7 +23,7 @@
> <parent>
> <groupId>org.apache.mina</groupId>
> <artifactId>mina-parent</artifactId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>mina-codec</artifactId>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/core/pom.xml
> ----------------------------------------------------------------------
> diff --git a/core/pom.xml b/core/pom.xml
> index 060e4fc..e03cae1 100644
> --- a/core/pom.xml
> +++ b/core/pom.xml
> @@ -23,7 +23,7 @@
> <parent>
> <groupId>org.apache.mina</groupId>
> <artifactId>mina-parent</artifactId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>mina-core</artifactId>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/distribution/pom.xml
> ----------------------------------------------------------------------
> diff --git a/distribution/pom.xml b/distribution/pom.xml
> index 2979c32..884889a 100644
> --- a/distribution/pom.xml
> +++ b/distribution/pom.xml
> @@ -24,7 +24,7 @@
> <parent>
> <artifactId>mina-parent</artifactId>
> <groupId>org.apache.mina</groupId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>distribution</artifactId>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/examples/pom.xml
> ----------------------------------------------------------------------
> diff --git a/examples/pom.xml b/examples/pom.xml
> index 9d98934..906cc70 100644
> --- a/examples/pom.xml
> +++ b/examples/pom.xml
> @@ -24,7 +24,7 @@
> <parent>
> <groupId>org.apache.mina</groupId>
> <artifactId>mina-parent</artifactId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>mina-examples</artifactId>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/http/pom.xml
> ----------------------------------------------------------------------
> diff --git a/http/pom.xml b/http/pom.xml
> index 19e2d04..653e04e 100644
> --- a/http/pom.xml
> +++ b/http/pom.xml
> @@ -24,7 +24,7 @@
> <parent>
> <groupId>org.apache.mina</groupId>
> <artifactId>mina-parent</artifactId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>mina-http</artifactId>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/pom.xml
> ----------------------------------------------------------------------
> diff --git a/pom.xml b/pom.xml
> index d35f0b6..796e205 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -33,7 +33,7 @@
> </organization>
>
> <groupId>org.apache.mina</groupId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> <artifactId>mina-parent</artifactId>
> <name>Apache MINA ${project.version}</name>
> <packaging>pom</packaging>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/protobuf/pom.xml
> ----------------------------------------------------------------------
> diff --git a/protobuf/pom.xml b/protobuf/pom.xml
> index b58165f..78e56b5 100644
> --- a/protobuf/pom.xml
> +++ b/protobuf/pom.xml
> @@ -23,7 +23,7 @@
> <parent>
> <groupId>org.apache.mina</groupId>
> <artifactId>mina-parent</artifactId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>mina-protobuf</artifactId>
>
> http://git-wip-us.apache.org/repos/asf/mina/blob/84b2003f/thrift/pom.xml
> ----------------------------------------------------------------------
> diff --git a/thrift/pom.xml b/thrift/pom.xml
> index a424384..7c28e33 100644
> --- a/thrift/pom.xml
> +++ b/thrift/pom.xml
> @@ -24,7 +24,7 @@
> <parent>
> <groupId>org.apache.mina</groupId>
> <artifactId>mina-parent</artifactId>
> - <version>3.0.0-M2-SNAPSHOT</version>
> + <version>3.0.0-M1</version>
> </parent>
>
> <artifactId>mina-thrift</artifactId>
>
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by Julien Vermillard <jv...@gmail.com>.
Thanks Jeff ! I think we should try it next time which should be soon in a
Milestone cycle.
Le 18 juil. 2013 00:31, "Jeff MAURY" <je...@jeffmaury.com> a écrit :
> The release plugin has a pushChanges flag for git which is true by default
> for preserving compatibility but could be useful.
>
> Jeff
>
>
> On Thu, Jul 18, 2013 at 12:26 AM, sebb <se...@gmail.com> wrote:
>
> > On 17 July 2013 23:19, Julien Vermillard <jv...@gmail.com> wrote:
> > > I think the main problem is maven release is pushing your modification
> > > when it could do all the work locally.
> >
> > It's not possible to do it all locally. It must at least commit the
> > tag to be used for the release vote.
> >
> > > perhaps we can configure that ?
> >
> > Good luck; I suspect this is buried deep within an undocumented plugin.
> >
> > > --
> > > Julien Vermillard :::: http://people.apache.org/~jvermillard/
> > >
> > >
> > > On Thu, Jul 18, 2013 at 12:07 AM, sebb <se...@gmail.com> wrote:
> > >> On 17 July 2013 17:44, Emmanuel Lécharny <el...@gmail.com> wrote:
> > >>> Le 7/17/13 6:15 PM, sebb a écrit :
> > >>>> On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> > >>>>> Le 7/17/13 5:53 PM, sebb a écrit :
> > >>>>>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com>
> > wrote:
> > >>>>>> With SVN the way I do it is:
> > >>>>> We don't use SVN anymore.
> > >>>> I realise that.
> > >>>>
> > >>>> Maybe Git offers functionality that would allow a similar approach
> > >>>> which achieves the same goals:
> > >>>> - don't leave trunk in a temporary state even for a short period
> > >>>> - make respins easier
> > >>>> - don't update trunk until actually ready to move to the next
> > >>>> development version
> > >>>
> > >>> This is why I proposed to create a temporary branch for the on-going
> > >>> release, leaving the trunk as is.
> > >>>
> > >>> I don't know how easy it is to do that with Maven.
> > >>
> > >> Maven can in theory do whatever the underlying SCM allows.
> > >> Whether the Maven project will agree to make the changes is another
> > matter.
> > >>
> > >> More to the point - does Git offer similar functionality to SVN for
> > >> this purpose?
> > >> I have no experience of Git, so I have no idea how to do it.
> > >>
> > >>> --
> > >>> Regards,
> > >>> Cordialement,
> > >>> Emmanuel Lécharny
> > >>> www.iktek.com
> > >>>
> >
>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
> - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury
>
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by Jeff MAURY <je...@jeffmaury.com>.
The release plugin has a pushChanges flag for git which is true by default
for preserving compatibility but could be useful.
Jeff
On Thu, Jul 18, 2013 at 12:26 AM, sebb <se...@gmail.com> wrote:
> On 17 July 2013 23:19, Julien Vermillard <jv...@gmail.com> wrote:
> > I think the main problem is maven release is pushing your modification
> > when it could do all the work locally.
>
> It's not possible to do it all locally. It must at least commit the
> tag to be used for the release vote.
>
> > perhaps we can configure that ?
>
> Good luck; I suspect this is buried deep within an undocumented plugin.
>
> > --
> > Julien Vermillard :::: http://people.apache.org/~jvermillard/
> >
> >
> > On Thu, Jul 18, 2013 at 12:07 AM, sebb <se...@gmail.com> wrote:
> >> On 17 July 2013 17:44, Emmanuel Lécharny <el...@gmail.com> wrote:
> >>> Le 7/17/13 6:15 PM, sebb a écrit :
> >>>> On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com> wrote:
> >>>>> Le 7/17/13 5:53 PM, sebb a écrit :
> >>>>>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> >>>>>> With SVN the way I do it is:
> >>>>> We don't use SVN anymore.
> >>>> I realise that.
> >>>>
> >>>> Maybe Git offers functionality that would allow a similar approach
> >>>> which achieves the same goals:
> >>>> - don't leave trunk in a temporary state even for a short period
> >>>> - make respins easier
> >>>> - don't update trunk until actually ready to move to the next
> >>>> development version
> >>>
> >>> This is why I proposed to create a temporary branch for the on-going
> >>> release, leaving the trunk as is.
> >>>
> >>> I don't know how easy it is to do that with Maven.
> >>
> >> Maven can in theory do whatever the underlying SCM allows.
> >> Whether the Maven project will agree to make the changes is another
> matter.
> >>
> >> More to the point - does Git offer similar functionality to SVN for
> >> this purpose?
> >> I have no experience of Git, so I have no idea how to do it.
> >>
> >>> --
> >>> Regards,
> >>> Cordialement,
> >>> Emmanuel Lécharny
> >>> www.iktek.com
> >>>
>
--
Jeff MAURY
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by Julien Vermillard <jv...@gmail.com>.
Committing a tag doesn't make much sense, it can be pushed afterward. It's
just a flag on a commit ID.
Le 18 juil. 2013 00:27, "sebb" <se...@gmail.com> a écrit :
> On 17 July 2013 23:19, Julien Vermillard <jv...@gmail.com> wrote:
> > I think the main problem is maven release is pushing your modification
> > when it could do all the work locally.
>
> It's not possible to do it all locally. It must at least commit the
> tag to be used for the release vote.
>
> > perhaps we can configure that ?
>
> Good luck; I suspect this is buried deep within an undocumented plugin.
>
> > --
> > Julien Vermillard :::: http://people.apache.org/~jvermillard/
> >
> >
> > On Thu, Jul 18, 2013 at 12:07 AM, sebb <se...@gmail.com> wrote:
> >> On 17 July 2013 17:44, Emmanuel Lécharny <el...@gmail.com> wrote:
> >>> Le 7/17/13 6:15 PM, sebb a écrit :
> >>>> On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com> wrote:
> >>>>> Le 7/17/13 5:53 PM, sebb a écrit :
> >>>>>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> >>>>>> With SVN the way I do it is:
> >>>>> We don't use SVN anymore.
> >>>> I realise that.
> >>>>
> >>>> Maybe Git offers functionality that would allow a similar approach
> >>>> which achieves the same goals:
> >>>> - don't leave trunk in a temporary state even for a short period
> >>>> - make respins easier
> >>>> - don't update trunk until actually ready to move to the next
> >>>> development version
> >>>
> >>> This is why I proposed to create a temporary branch for the on-going
> >>> release, leaving the trunk as is.
> >>>
> >>> I don't know how easy it is to do that with Maven.
> >>
> >> Maven can in theory do whatever the underlying SCM allows.
> >> Whether the Maven project will agree to make the changes is another
> matter.
> >>
> >> More to the point - does Git offer similar functionality to SVN for
> >> this purpose?
> >> I have no experience of Git, so I have no idea how to do it.
> >>
> >>> --
> >>> Regards,
> >>> Cordialement,
> >>> Emmanuel Lécharny
> >>> www.iktek.com
> >>>
>
Re: git commit: Revert "[maven-release-plugin] prepare for next development
iteration"
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/18/13 12:26 AM, sebb a écrit :
> On 17 July 2013 23:19, Julien Vermillard <jv...@gmail.com> wrote:
>> I think the main problem is maven release is pushing your modification
>> when it could do all the work locally.
> It's not possible to do it all locally. It must at least commit the
> tag to be used for the release vote.
Yes, and this is why I thought that pushing the release into a branch is
the way to go (if maven allows that)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by sebb <se...@gmail.com>.
On 17 July 2013 23:19, Julien Vermillard <jv...@gmail.com> wrote:
> I think the main problem is maven release is pushing your modification
> when it could do all the work locally.
It's not possible to do it all locally. It must at least commit the
tag to be used for the release vote.
> perhaps we can configure that ?
Good luck; I suspect this is buried deep within an undocumented plugin.
> --
> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>
>
> On Thu, Jul 18, 2013 at 12:07 AM, sebb <se...@gmail.com> wrote:
>> On 17 July 2013 17:44, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 7/17/13 6:15 PM, sebb a écrit :
>>>> On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>>> Le 7/17/13 5:53 PM, sebb a écrit :
>>>>>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>>>> With SVN the way I do it is:
>>>>> We don't use SVN anymore.
>>>> I realise that.
>>>>
>>>> Maybe Git offers functionality that would allow a similar approach
>>>> which achieves the same goals:
>>>> - don't leave trunk in a temporary state even for a short period
>>>> - make respins easier
>>>> - don't update trunk until actually ready to move to the next
>>>> development version
>>>
>>> This is why I proposed to create a temporary branch for the on-going
>>> release, leaving the trunk as is.
>>>
>>> I don't know how easy it is to do that with Maven.
>>
>> Maven can in theory do whatever the underlying SCM allows.
>> Whether the Maven project will agree to make the changes is another matter.
>>
>> More to the point - does Git offer similar functionality to SVN for
>> this purpose?
>> I have no experience of Git, so I have no idea how to do it.
>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by Julien Vermillard <jv...@gmail.com>.
I think the main problem is maven release is pushing your modification
when it could do all the work locally.
perhaps we can configure that ?
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
On Thu, Jul 18, 2013 at 12:07 AM, sebb <se...@gmail.com> wrote:
> On 17 July 2013 17:44, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/17/13 6:15 PM, sebb a écrit :
>>> On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>> Le 7/17/13 5:53 PM, sebb a écrit :
>>>>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>>> With SVN the way I do it is:
>>>> We don't use SVN anymore.
>>> I realise that.
>>>
>>> Maybe Git offers functionality that would allow a similar approach
>>> which achieves the same goals:
>>> - don't leave trunk in a temporary state even for a short period
>>> - make respins easier
>>> - don't update trunk until actually ready to move to the next
>>> development version
>>
>> This is why I proposed to create a temporary branch for the on-going
>> release, leaving the trunk as is.
>>
>> I don't know how easy it is to do that with Maven.
>
> Maven can in theory do whatever the underlying SCM allows.
> Whether the Maven project will agree to make the changes is another matter.
>
> More to the point - does Git offer similar functionality to SVN for
> this purpose?
> I have no experience of Git, so I have no idea how to do it.
>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by sebb <se...@gmail.com>.
On 17 July 2013 17:44, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/17/13 6:15 PM, sebb a écrit :
>> On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 7/17/13 5:53 PM, sebb a écrit :
>>>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>> With SVN the way I do it is:
>>> We don't use SVN anymore.
>> I realise that.
>>
>> Maybe Git offers functionality that would allow a similar approach
>> which achieves the same goals:
>> - don't leave trunk in a temporary state even for a short period
>> - make respins easier
>> - don't update trunk until actually ready to move to the next
>> development version
>
> This is why I proposed to create a temporary branch for the on-going
> release, leaving the trunk as is.
>
> I don't know how easy it is to do that with Maven.
Maven can in theory do whatever the underlying SCM allows.
Whether the Maven project will agree to make the changes is another matter.
More to the point - does Git offer similar functionality to SVN for
this purpose?
I have no experience of Git, so I have no idea how to do it.
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: git commit: Revert "[maven-release-plugin] prepare for next development
iteration"
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/17/13 6:15 PM, sebb a écrit :
> On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/17/13 5:53 PM, sebb a écrit :
>>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> With SVN the way I do it is:
>> We don't use SVN anymore.
> I realise that.
>
> Maybe Git offers functionality that would allow a similar approach
> which achieves the same goals:
> - don't leave trunk in a temporary state even for a short period
> - make respins easier
> - don't update trunk until actually ready to move to the next
> development version
This is why I proposed to create a temporary branch for the on-going
release, leaving the trunk as is.
I don't know how easy it is to do that with Maven.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by sebb <se...@gmail.com>.
On 17 July 2013 17:00, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/17/13 5:53 PM, sebb a écrit :
>> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 7/17/13 3:00 PM, sebb a écrit :
>>>> On 17 July 2013 13:26, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>>> Le 7/17/13 2:21 PM, sebb a écrit :
>>>>>> On 17 July 2013 10:56, <el...@apache.org> wrote:
>>>>>>> Updated Branches:
>>>>>>> refs/heads/trunk 0d04eba45 -> 84b2003fc
>>>>>>>
>>>>>>>
>>>>>>> Revert "[maven-release-plugin] prepare for next development iteration"
>>>>>>>
>>>>>>> This reverts commit 0d04eba4525ca85886c4a03acc20b444ff69a52d.
>>>>>> However trunk is now in an incorrect state, as all the versions are
>>>>>> missing the -SNAPSHOT suffix.
>>>>> The trunk will be fix when the perform will be done. (Actually, it
>>>>> should be the case).
>>>> But meanwhile any builds (including CI builds) will be using the
>>>> non-SNAPSHOT version.
>>>> Not ideal.
>>> Yep. The plugin should rather create a branch, instead of committing in
>>> trunk...
>> No, it does not need to do that - at least not with SVN.
>>
>> With SVN the way I do it is:
> We don't use SVN anymore.
I realise that.
Maybe Git offers functionality that would allow a similar approach
which achieves the same goals:
- don't leave trunk in a temporary state even for a short period
- make respins easier
- don't update trunk until actually ready to move to the next
development version
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: git commit: Revert "[maven-release-plugin] prepare for next development
iteration"
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/17/13 5:53 PM, sebb a écrit :
> On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/17/13 3:00 PM, sebb a écrit :
>>> On 17 July 2013 13:26, Emmanuel Lécharny <el...@gmail.com> wrote:
>>>> Le 7/17/13 2:21 PM, sebb a écrit :
>>>>> On 17 July 2013 10:56, <el...@apache.org> wrote:
>>>>>> Updated Branches:
>>>>>> refs/heads/trunk 0d04eba45 -> 84b2003fc
>>>>>>
>>>>>>
>>>>>> Revert "[maven-release-plugin] prepare for next development iteration"
>>>>>>
>>>>>> This reverts commit 0d04eba4525ca85886c4a03acc20b444ff69a52d.
>>>>> However trunk is now in an incorrect state, as all the versions are
>>>>> missing the -SNAPSHOT suffix.
>>>> The trunk will be fix when the perform will be done. (Actually, it
>>>> should be the case).
>>> But meanwhile any builds (including CI builds) will be using the
>>> non-SNAPSHOT version.
>>> Not ideal.
>> Yep. The plugin should rather create a branch, instead of committing in
>> trunk...
> No, it does not need to do that - at least not with SVN.
>
> With SVN the way I do it is:
We don't use SVN anymore.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by sebb <se...@gmail.com>.
On 17 July 2013 15:19, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/17/13 3:00 PM, sebb a écrit :
>> On 17 July 2013 13:26, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 7/17/13 2:21 PM, sebb a écrit :
>>>> On 17 July 2013 10:56, <el...@apache.org> wrote:
>>>>> Updated Branches:
>>>>> refs/heads/trunk 0d04eba45 -> 84b2003fc
>>>>>
>>>>>
>>>>> Revert "[maven-release-plugin] prepare for next development iteration"
>>>>>
>>>>> This reverts commit 0d04eba4525ca85886c4a03acc20b444ff69a52d.
>>>> However trunk is now in an incorrect state, as all the versions are
>>>> missing the -SNAPSHOT suffix.
>>> The trunk will be fix when the perform will be done. (Actually, it
>>> should be the case).
>> But meanwhile any builds (including CI builds) will be using the
>> non-SNAPSHOT version.
>> Not ideal.
>
> Yep. The plugin should rather create a branch, instead of committing in
> trunk...
No, it does not need to do that - at least not with SVN.
With SVN the way I do it is:
Checkout trunk in a separate clean directory
Fix the versions / URLs etc
Create the tag directly from the workspace using SVN copy.
SVN is clever enough to realise that the only changes are the ones
made to the workspace.
And at the end of the process, trunk is untouched (so respins are trivial)
And you have a nice clean workspace which is available for builds.
Once the release succeeds, of course trunk has to be updated to the
next SNAPSHOT.
But it can never be left in a partially updated state.
> In the current case, I was absent around 1h30 between the prepare and
> perform, enough for someone to notice the pb. But even if I were to do
> the perform immediately, on a bigger project, that would be an issue.
>
> I'll try to see with the maven fellows if we can improve this process.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: git commit: Revert "[maven-release-plugin] prepare for next development
iteration"
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/17/13 3:00 PM, sebb a écrit :
> On 17 July 2013 13:26, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/17/13 2:21 PM, sebb a écrit :
>>> On 17 July 2013 10:56, <el...@apache.org> wrote:
>>>> Updated Branches:
>>>> refs/heads/trunk 0d04eba45 -> 84b2003fc
>>>>
>>>>
>>>> Revert "[maven-release-plugin] prepare for next development iteration"
>>>>
>>>> This reverts commit 0d04eba4525ca85886c4a03acc20b444ff69a52d.
>>> However trunk is now in an incorrect state, as all the versions are
>>> missing the -SNAPSHOT suffix.
>> The trunk will be fix when the perform will be done. (Actually, it
>> should be the case).
> But meanwhile any builds (including CI builds) will be using the
> non-SNAPSHOT version.
> Not ideal.
Yep. The plugin should rather create a branch, instead of committing in
trunk...
In the current case, I was absent around 1h30 between the prepare and
perform, enough for someone to notice the pb. But even if I were to do
the perform immediately, on a bigger project, that would be an issue.
I'll try to see with the maven fellows if we can improve this process.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: git commit: Revert "[maven-release-plugin] prepare for next
development iteration"
Posted by sebb <se...@gmail.com>.
On 17 July 2013 13:26, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/17/13 2:21 PM, sebb a écrit :
>> On 17 July 2013 10:56, <el...@apache.org> wrote:
>>> Updated Branches:
>>> refs/heads/trunk 0d04eba45 -> 84b2003fc
>>>
>>>
>>> Revert "[maven-release-plugin] prepare for next development iteration"
>>>
>>> This reverts commit 0d04eba4525ca85886c4a03acc20b444ff69a52d.
>> However trunk is now in an incorrect state, as all the versions are
>> missing the -SNAPSHOT suffix.
>
> The trunk will be fix when the perform will be done. (Actually, it
> should be the case).
But meanwhile any builds (including CI builds) will be using the
non-SNAPSHOT version.
Not ideal.
Luckily we now have Nexus to intercept any deploy jobs.
This is really a problem with the release plugin; it's easy to use it
incorrectly, and it does not fail-safe.
But it's something users should be aware of.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: git commit: Revert "[maven-release-plugin] prepare for next development
iteration"
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/17/13 2:21 PM, sebb a écrit :
> On 17 July 2013 10:56, <el...@apache.org> wrote:
>> Updated Branches:
>> refs/heads/trunk 0d04eba45 -> 84b2003fc
>>
>>
>> Revert "[maven-release-plugin] prepare for next development iteration"
>>
>> This reverts commit 0d04eba4525ca85886c4a03acc20b444ff69a52d.
> However trunk is now in an incorrect state, as all the versions are
> missing the -SNAPSHOT suffix.
The trunk will be fix when the perform will be done. (Actually, it
should be the case).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com