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.ocleir...@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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
