You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Michael O'Cleirigh <mi...@rivulet.ca> on 2011/03/26 21:13:08 UTC
[wicketstuff-core] Wicketstuff Developers please use a separate commit
when fixing breakage due to wicket upstream changes
Hello,
Because of how the wicketstuff-core release process works there is the
possibility that the current wicket upstream contains changes that are
different from the latest stable wicket release.
When I create a release branch I do so at the top of the present
development branch (core-1.4.x or master) and then just change the
<wicket.version> property in the top pom.xml file. At this point when I
build if there is this divergence in features between the upstream
wicket releases the build will break.
My approach is to find the commit that last changed the file and then
use git revert $commit to undo it. This works perfectly when the only
files that changed in a particular commit were those related to the
upstream change.
The purpose of this email is to ask wicketstuff developers to continue
this practice of a separate commit to contain upstream related changes
to make it simple for me at release time to revert changes.
If you look at the commits for the wicketstuff-core-1.5-rc2.1 tag you
can see several reverts were required to get things to compile with
wicket 1.5-rc2. This worked great because the commits only dealt with
upstream changes.
Thanks,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [wicketstuff-core] Wicketstuff Developers please use a separate
commit when fixing breakage due to wicket upstream changes
Posted by Bruno Borges <br...@gmail.com>.
Wow... got it. Thanks for clarifying all of this.
Now, I think it is hard to guarantee no one will push API changes + features
on a unique commit.
Shouldn't we consider to stop building for point releases and only release
after a stable Wicket version? (ie. not RC's)
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
On Sun, Mar 27, 2011 at 10:56 PM, Michael O'Cleirigh <
michael.ocleirigh@rivulet.ca> wrote:
> Hi Bruno,
>
> Actually everything was fine with the 1.5-rc2.1 release but I just wanted
> to make sure that future releases would be trouble free as well. This is
> just a possible edge case issue when doing point releases (it does not apply
> for the first release on a given wicket release).
>
> This is the scenario:
>
> A--B--C--D
> \
> E--F--G
>
> A is the point that we released 1.5-rc2 and when the wicket 1.5-rc2 release
> was available.
>
> D is the point that the wicket 1.5-SNAPSHOT release contained API changes
> that were not in wicket 1.5-rc2
>
> E and G are new feature commits related to modules within wicketstuff.
>
> F is a commit to fix API breakage introduced by the current wicket
> 1.5-SNAPSHOT.
>
> Ok so when I cut a new release I create a new branch after commit G and
> then:
> 1. change the pom version to the 1.5-rc2.1 release
> 2. change the wicket.version property to 1.5-rc2.1.
>
> At this point I get compile errors because of the files changed in commit
> F. But because commit F only contains the changes related to the upstream
> API changes I can quickly just revert it (git revert F) to undo the changes
> and bring the code back into compatibility with wicket-1.5-rc2 and then get
> on with cutting the release.
>
> As I mentioned everything was fine this time because the changes related to
> upstream API changes were isolated in separate commits. What I am asking is
> that this remain the case and wicketstuff developers don't create commits
> that combine upstream api and feature commits.
>
> i.e. if commits F and G were one commit H then when I revert it (git revert
> H) I would also take out api changes that are probably useful and should
> not have been taken out. Or worse it could leave the project unbuildable
> and I would have to hunt through the commits trying to separate out the
> upstream api change from the feature change which would distract from doing
> the actual release.
>
> Regards,
>
> Mike
>
>
>
>
>
> Michael, could you better explain what exactly happened? I'm not an expert
>> on Git, but I really want to understand what to do.
>>
>> Thanks,
>>
>> PS: and thank you very much. You've been doing a great job at keeping
>> wicketstuff alive and functional... :-)
>>
>> Bruno Borges
>> www.brunoborges.com.br
>> +55 21 76727099
>>
>> "The glory of great men should always be
>> measured by the means they have used to
>> acquire it."
>> - Francois de La Rochefoucauld
>>
>>
>>
>> On Sat, Mar 26, 2011 at 5:13 PM, Michael O'Cleirigh<
>> michael.ocleirigh@rivulet.ca> wrote:
>>
>> Hello,
>>>
>>> Because of how the wicketstuff-core release process works there is the
>>> possibility that the current wicket upstream contains changes that are
>>> different from the latest stable wicket release.
>>>
>>> When I create a release branch I do so at the top of the present
>>> development branch (core-1.4.x or master) and then just change the
>>> <wicket.version> property in the top pom.xml file. At this point when I
>>> build if there is this divergence in features between the upstream
>>> wicket
>>> releases the build will break.
>>>
>>> My approach is to find the commit that last changed the file and then use
>>> git revert $commit to undo it. This works perfectly when the only files
>>> that changed in a particular commit were those related to the upstream
>>> change.
>>>
>>> The purpose of this email is to ask wicketstuff developers to continue
>>> this
>>> practice of a separate commit to contain upstream related changes to make
>>> it
>>> simple for me at release time to revert changes.
>>>
>>> If you look at the commits for the wicketstuff-core-1.5-rc2.1 tag you can
>>> see several reverts were required to get things to compile with wicket
>>> 1.5-rc2. This worked great because the commits only dealt with upstream
>>> changes.
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>
>>>
>>>
>
Re: [wicketstuff-core] Wicketstuff Developers please use a separate
commit when fixing breakage due to wicket upstream changes
Posted by Bruno Borges <br...@gmail.com>.
Wow... got it. Thanks for clarifying all of this.
Now, I think it is hard to guarantee no one will push API changes + features
on a unique commit.
Shouldn't we consider to stop building for point releases and only release
after a stable Wicket version? (ie. not RC's)
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
On Sun, Mar 27, 2011 at 10:56 PM, Michael O'Cleirigh <
michael.ocleirigh@rivulet.ca> wrote:
> Hi Bruno,
>
> Actually everything was fine with the 1.5-rc2.1 release but I just wanted
> to make sure that future releases would be trouble free as well. This is
> just a possible edge case issue when doing point releases (it does not apply
> for the first release on a given wicket release).
>
> This is the scenario:
>
> A--B--C--D
> \
> E--F--G
>
> A is the point that we released 1.5-rc2 and when the wicket 1.5-rc2 release
> was available.
>
> D is the point that the wicket 1.5-SNAPSHOT release contained API changes
> that were not in wicket 1.5-rc2
>
> E and G are new feature commits related to modules within wicketstuff.
>
> F is a commit to fix API breakage introduced by the current wicket
> 1.5-SNAPSHOT.
>
> Ok so when I cut a new release I create a new branch after commit G and
> then:
> 1. change the pom version to the 1.5-rc2.1 release
> 2. change the wicket.version property to 1.5-rc2.1.
>
> At this point I get compile errors because of the files changed in commit
> F. But because commit F only contains the changes related to the upstream
> API changes I can quickly just revert it (git revert F) to undo the changes
> and bring the code back into compatibility with wicket-1.5-rc2 and then get
> on with cutting the release.
>
> As I mentioned everything was fine this time because the changes related to
> upstream API changes were isolated in separate commits. What I am asking is
> that this remain the case and wicketstuff developers don't create commits
> that combine upstream api and feature commits.
>
> i.e. if commits F and G were one commit H then when I revert it (git revert
> H) I would also take out api changes that are probably useful and should
> not have been taken out. Or worse it could leave the project unbuildable
> and I would have to hunt through the commits trying to separate out the
> upstream api change from the feature change which would distract from doing
> the actual release.
>
> Regards,
>
> Mike
>
>
>
>
>
> Michael, could you better explain what exactly happened? I'm not an expert
>> on Git, but I really want to understand what to do.
>>
>> Thanks,
>>
>> PS: and thank you very much. You've been doing a great job at keeping
>> wicketstuff alive and functional... :-)
>>
>> Bruno Borges
>> www.brunoborges.com.br
>> +55 21 76727099
>>
>> "The glory of great men should always be
>> measured by the means they have used to
>> acquire it."
>> - Francois de La Rochefoucauld
>>
>>
>>
>> On Sat, Mar 26, 2011 at 5:13 PM, Michael O'Cleirigh<
>> michael.ocleirigh@rivulet.ca> wrote:
>>
>> Hello,
>>>
>>> Because of how the wicketstuff-core release process works there is the
>>> possibility that the current wicket upstream contains changes that are
>>> different from the latest stable wicket release.
>>>
>>> When I create a release branch I do so at the top of the present
>>> development branch (core-1.4.x or master) and then just change the
>>> <wicket.version> property in the top pom.xml file. At this point when I
>>> build if there is this divergence in features between the upstream
>>> wicket
>>> releases the build will break.
>>>
>>> My approach is to find the commit that last changed the file and then use
>>> git revert $commit to undo it. This works perfectly when the only files
>>> that changed in a particular commit were those related to the upstream
>>> change.
>>>
>>> The purpose of this email is to ask wicketstuff developers to continue
>>> this
>>> practice of a separate commit to contain upstream related changes to make
>>> it
>>> simple for me at release time to revert changes.
>>>
>>> If you look at the commits for the wicketstuff-core-1.5-rc2.1 tag you can
>>> see several reverts were required to get things to compile with wicket
>>> 1.5-rc2. This worked great because the commits only dealt with upstream
>>> changes.
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>
>>>
>>>
>
Re: [wicketstuff-core] Wicketstuff Developers please use a separate
commit when fixing breakage due to wicket upstream changes
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hi Bruno,
Actually everything was fine with the 1.5-rc2.1 release but I just
wanted to make sure that future releases would be trouble free as well.
This is just a possible edge case issue when doing point releases (it
does not apply for the first release on a given wicket release).
This is the scenario:
A--B--C--D
\
E--F--G
A is the point that we released 1.5-rc2 and when the wicket 1.5-rc2
release was available.
D is the point that the wicket 1.5-SNAPSHOT release contained API
changes that were not in wicket 1.5-rc2
E and G are new feature commits related to modules within wicketstuff.
F is a commit to fix API breakage introduced by the current wicket
1.5-SNAPSHOT.
Ok so when I cut a new release I create a new branch after commit G and
then:
1. change the pom version to the 1.5-rc2.1 release
2. change the wicket.version property to 1.5-rc2.1.
At this point I get compile errors because of the files changed in
commit F. But because commit F only contains the changes related to the
upstream API changes I can quickly just revert it (git revert F) to undo
the changes and bring the code back into compatibility with
wicket-1.5-rc2 and then get on with cutting the release.
As I mentioned everything was fine this time because the changes related
to upstream API changes were isolated in separate commits. What I am
asking is that this remain the case and wicketstuff developers don't
create commits that combine upstream api and feature commits.
i.e. if commits F and G were one commit H then when I revert it (git
revert H) I would also take out api changes that are probably useful
and should not have been taken out. Or worse it could leave the project
unbuildable and I would have to hunt through the commits trying to
separate out the upstream api change from the feature change which would
distract from doing the actual release.
Regards,
Mike
> Michael, could you better explain what exactly happened? I'm not an expert
> on Git, but I really want to understand what to do.
>
> Thanks,
>
> PS: and thank you very much. You've been doing a great job at keeping
> wicketstuff alive and functional... :-)
>
> Bruno Borges
> www.brunoborges.com.br
> +55 21 76727099
>
> "The glory of great men should always be
> measured by the means they have used to
> acquire it."
> - Francois de La Rochefoucauld
>
>
>
> On Sat, Mar 26, 2011 at 5:13 PM, Michael O'Cleirigh<
> michael.ocleirigh@rivulet.ca> wrote:
>
>> Hello,
>>
>> Because of how the wicketstuff-core release process works there is the
>> possibility that the current wicket upstream contains changes that are
>> different from the latest stable wicket release.
>>
>> When I create a release branch I do so at the top of the present
>> development branch (core-1.4.x or master) and then just change the
>> <wicket.version> property in the top pom.xml file. At this point when I
>> build if there is this divergence in features between the upstream wicket
>> releases the build will break.
>>
>> My approach is to find the commit that last changed the file and then use
>> git revert $commit to undo it. This works perfectly when the only files
>> that changed in a particular commit were those related to the upstream
>> change.
>>
>> The purpose of this email is to ask wicketstuff developers to continue this
>> practice of a separate commit to contain upstream related changes to make it
>> simple for me at release time to revert changes.
>>
>> If you look at the commits for the wicketstuff-core-1.5-rc2.1 tag you can
>> see several reverts were required to get things to compile with wicket
>> 1.5-rc2. This worked great because the commits only dealt with upstream
>> changes.
>>
>> Thanks,
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail:users-help@wicket.apache.org
>>
>>
Re: [wicketstuff-core] Wicketstuff Developers please use a separate
commit when fixing breakage due to wicket upstream changes
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hi Bruno,
Actually everything was fine with the 1.5-rc2.1 release but I just
wanted to make sure that future releases would be trouble free as well.
This is just a possible edge case issue when doing point releases (it
does not apply for the first release on a given wicket release).
This is the scenario:
A--B--C--D
\
E--F--G
A is the point that we released 1.5-rc2 and when the wicket 1.5-rc2
release was available.
D is the point that the wicket 1.5-SNAPSHOT release contained API
changes that were not in wicket 1.5-rc2
E and G are new feature commits related to modules within wicketstuff.
F is a commit to fix API breakage introduced by the current wicket
1.5-SNAPSHOT.
Ok so when I cut a new release I create a new branch after commit G and
then:
1. change the pom version to the 1.5-rc2.1 release
2. change the wicket.version property to 1.5-rc2.1.
At this point I get compile errors because of the files changed in
commit F. But because commit F only contains the changes related to the
upstream API changes I can quickly just revert it (git revert F) to undo
the changes and bring the code back into compatibility with
wicket-1.5-rc2 and then get on with cutting the release.
As I mentioned everything was fine this time because the changes related
to upstream API changes were isolated in separate commits. What I am
asking is that this remain the case and wicketstuff developers don't
create commits that combine upstream api and feature commits.
i.e. if commits F and G were one commit H then when I revert it (git
revert H) I would also take out api changes that are probably useful
and should not have been taken out. Or worse it could leave the project
unbuildable and I would have to hunt through the commits trying to
separate out the upstream api change from the feature change which would
distract from doing the actual release.
Regards,
Mike
> Michael, could you better explain what exactly happened? I'm not an expert
> on Git, but I really want to understand what to do.
>
> Thanks,
>
> PS: and thank you very much. You've been doing a great job at keeping
> wicketstuff alive and functional... :-)
>
> Bruno Borges
> www.brunoborges.com.br
> +55 21 76727099
>
> "The glory of great men should always be
> measured by the means they have used to
> acquire it."
> - Francois de La Rochefoucauld
>
>
>
> On Sat, Mar 26, 2011 at 5:13 PM, Michael O'Cleirigh<
> michael.ocleirigh@rivulet.ca> wrote:
>
>> Hello,
>>
>> Because of how the wicketstuff-core release process works there is the
>> possibility that the current wicket upstream contains changes that are
>> different from the latest stable wicket release.
>>
>> When I create a release branch I do so at the top of the present
>> development branch (core-1.4.x or master) and then just change the
>> <wicket.version> property in the top pom.xml file. At this point when I
>> build if there is this divergence in features between the upstream wicket
>> releases the build will break.
>>
>> My approach is to find the commit that last changed the file and then use
>> git revert $commit to undo it. This works perfectly when the only files
>> that changed in a particular commit were those related to the upstream
>> change.
>>
>> The purpose of this email is to ask wicketstuff developers to continue this
>> practice of a separate commit to contain upstream related changes to make it
>> simple for me at release time to revert changes.
>>
>> If you look at the commits for the wicketstuff-core-1.5-rc2.1 tag you can
>> see several reverts were required to get things to compile with wicket
>> 1.5-rc2. This worked great because the commits only dealt with upstream
>> changes.
>>
>> Thanks,
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail:users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [wicketstuff-core] Wicketstuff Developers please use a separate
commit when fixing breakage due to wicket upstream changes
Posted by Bruno Borges <br...@gmail.com>.
Michael, could you better explain what exactly happened? I'm not an expert
on Git, but I really want to understand what to do.
Thanks,
PS: and thank you very much. You've been doing a great job at keeping
wicketstuff alive and functional... :-)
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
On Sat, Mar 26, 2011 at 5:13 PM, Michael O'Cleirigh <
michael.ocleirigh@rivulet.ca> wrote:
> Hello,
>
> Because of how the wicketstuff-core release process works there is the
> possibility that the current wicket upstream contains changes that are
> different from the latest stable wicket release.
>
> When I create a release branch I do so at the top of the present
> development branch (core-1.4.x or master) and then just change the
> <wicket.version> property in the top pom.xml file. At this point when I
> build if there is this divergence in features between the upstream wicket
> releases the build will break.
>
> My approach is to find the commit that last changed the file and then use
> git revert $commit to undo it. This works perfectly when the only files
> that changed in a particular commit were those related to the upstream
> change.
>
> The purpose of this email is to ask wicketstuff developers to continue this
> practice of a separate commit to contain upstream related changes to make it
> simple for me at release time to revert changes.
>
> If you look at the commits for the wicketstuff-core-1.5-rc2.1 tag you can
> see several reverts were required to get things to compile with wicket
> 1.5-rc2. This worked great because the commits only dealt with upstream
> changes.
>
> Thanks,
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>