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 < [email protected]> 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< >> [email protected]> 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:[email protected] >>> For additional commands, e-mail:[email protected] >>> >>> >>> >
