I think this sounds good, and meshes with the comments several other
people have made. So I think we're converging on a general agreement
for a process. Documenting it on the wiki would be great.
If there are no objections, I can take the first step in this process,
which would seem to be setting wicketstuff-core's dependency to wicket
1.4.7, and then asking people to test it. We should probably set a date
by which we ask people to test out the modules they use -- otherwise if
no issues are reported we won't know when to declare the testing period
over and actually do the release.
How do people feel about the other dependencies in there (jetty, slf4j,
etc)? Should we just as a matter of course re-point those to the latest
stable versions when we do a version bump of wicket and are heading into
a round of testing?
Bng
Michael O'Cleirigh wrote:
Hello,
I'd like the trunk to follow the latest wicket release since when
wicketstuff-core is released it is meant to be paired with the current
wicket release. i.e. not 1.4-SNAPSHOT but 1.4.7, 1.4.8, 1.4.9 and
eventually into 1.5RC1, etc.
Envisioned Process for 1.4.8 Wicket Release:
1. wicket releases new version 1.4.8
2. wicketstuff-core pom is updated for 1.4.8
3. organized testing and vote on release.
4. release (non SNAPSHOT) artifacts are generated and pushed into
maven and a svn:/tags/wicketstuff-core-1.4.8 tag is created
5. trunk pom's are changed back to wicketstuff-core version of
1.4-SNAPSHOT
I think we should only cut one release per wicket main release and any
other changes just go automatically into the 1.4-SNAPSHOT releases
that are generated when a developer commits. If a user needs new
features in the gap between releases they can just get the SNAPSHOT
releases.
+1 for creating a svn:/branches/wicketstuff-core-1.4 when trunk
switches to the 1.5 RC's. We can then support two release lines but
everying is tied to wicket main releases. When wicket end of life's
the 1.4.x line there will be no more releases just snapshots. Also
there should be no developer requirement to sync the 1.4 and 1.5
branch project contents (i.e. supporting two lines) just maintenance
on 1.4 branch and new development on trunk.
+1 on creating wicketstuff-core jira to coordinate release process.
+1 on creating a wicketstuff-core/wicketstuff-test module to share
testing code between core projects.
+1 on running integration tests to find run-time issues before release
on the generated project artifacts (i.e. like selenium through maven
integration-test phase). I know this is hard but maybe a special
profile in the pom to allow these extended quality checks to be run
outside of a continuous integration environment prior to release.
+1 improving the wicketstuff developer wiki with details on how the
release process works (I'm volunteering)
Regards,
Mike
Id vote for this one:
modify the trunk
first for 1.4.7 fix the incompatibilities if there are, and then release
it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
And if you like sonar, it's opensource and requires almost no setup it
has a fluent plugin with maven. For example theres a pretty good
integration between hudson, I could'nt find one for team city though
:/ But in theory it's just running the mvn command sonar:sonar..
2010/3/23 Major Péter<majorpe...@sch.bme.hu>:
Tests are good, but this could be also arranged with voting, or not?
So what would be the best?
Modify the trunk to use 1.4.7, and release the current state as
wicketstuff 1.4.1 (because it's using 1.4.1 now) or modify the trunk
first for 1.4.7 fix the incompatibilities if there are, and then
release
it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
Or what else do you have in mind?
This sonarsource is good stuff, +1.
Peter
2010-03-23 12:33 keltezéssel, nino martinez wael írta:
+1 for me on upgrading wicketstuff core to 1.4.7.
On another topic making sure that an upgrade actually works are
another thing. Code might compile but there could be runtime
problems.. I discussed looong time ago a possibility for making tests
for the javascript parts of the code aswell, with rhino... We could'nt
really call it stable until we made sure it where that. On another
node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as
it would help showing code metrics etc..
2010/3/23 Stefan Lindner<lind...@visionet.de>:
Should we really start with a big bang? Support wicketstuff STABLE
core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in
sight? Or does this mean everything in wicketstuff will stay as it
is for a long time?
Why not start with a smaller step and create a core wicketstuff
release for current wicket 1.4?
Stefan
-----Ursprüngliche Nachricht-----
Von: Major Péter [mailto:majorpe...@sch.bme.hu]
Gesendet: Dienstag, 23. März 2010 11:38
An: users@wicket.apache.org
Betreff: Re: Wicketstuff versioning
2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
branch until/unless someone actually wants to commit some code that
would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch,
we have
to start committing every bug fix to two different versions, right?
Yes, you're right about this, maybe we should wait until the first
1.5
RC with it.
If we're lucky, everything in Wicketstuff may work fine unchanged
with
1.4 and 1.5, and I suggest we can save ourselves a large amount of
headache by just maintaining a single trunk, and bumping the version
after there's an official Wicket release.
As far as I saw, there was some major modifications in the core
around
the request-handling and URL-strategies, so this could rise up
some issues.
Of course, correct me if I'm wrong. I don't know how fundamentally
different wicket 1.5 is going to be, or if there are a lot of people
running snapshots of it now who would need Wicketstuff to be
tracking
it.
Is 1.5 RC1 good for everyone? :)
Regards,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
