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]
