+1 on the sp<number> postfix for all gwt-m-p's and of course the test harness
- Robert From: [email protected] Date: Thu, 2 Sep 2010 21:14:01 +0200 To: [email protected] Subject: Re: [mojo-dev] [Vote] [gwt] align gwt-maven releases with GWT ones GWT has followed this convention for a while, I can't see reason they change this. Also notice Google guys WANT to intergate nicelly into maven, so we can expect them not to make breaking changes without a chance for us to warn. another thing to consider, is that such multi release of gwt-maven for a single gwt release will only for critical bug fixes, so that we can consider any other naming scheme when this happen, x.y.z.sp1, x.y.z.fix1 ot whatever we want. Anyway, user requiring a bugfix used to rely on SNAPSHOT as we did few releases in the past. Considering two years of gwt-maven-plugin GWT released minor releases 3 or 4 time quicker than we do, so we have many reason to wait next release to integrate bug fixes. The best way to avoid breaking bugs would be to have a test harness, that we don't have today. This will be my major task after 2.1 release... Nicolas 2010/9/2 Robert Scholte <[email protected]> So this ASSUMES that GWT will follow the x.y.z version pattern (and as we all know: assumption is the mother of all....). I think there are two options: version could look like x.y.z.a, where 'a' is the plugin-version for GWT x.y.z, or x.y.z-mgwt-1.0 or something like that. The latter is always safe, but it'll result in an ugly version pattern and I hope Maven can handle such version (I believe so) - Robert From: [email protected] Date: Thu, 2 Sep 2010 08:12:36 +0200 To: [email protected] Subject: Re: [mojo-dev] [Vote] [gwt] align gwt-maven releases with GWT ones GWT minor releases come often (more more often gwt-maven ones) For critical bugfix releases, we can release a <gwt version x.y.z>.fix release. Next GWT version is 2.1.0, and if we discover a critical bug we can release a 2.1.0.1. Considering two years of dev on this plugin, we can also wait for next gwt minor release that occured quicker than the time required for us to fix a bug :P 2010/9/1 Robert Scholte <[email protected]> I have my doubts... I don't know the amount of time it usualy takes before GWT comes with a new release, but if this takes too long, we might run into some trouble. What if we have bugfixes and new features on a already released version? Suppose we have GWT-2.1 and the gwt-m-p-2.1, should the fixed version be gwt-m-p-2.1.1? Gotcha!, because a week later GWT also discovered some serious issues and releases a 2.1.1 as well. Now both versions are out of sync again. It might sounds logic, but I think it would only work if GWT itself releases the maven plugin as part of a suite. Although the versions are pretty close to each other, I wouldn't try to follow the GWT-version. - Robert > From: [email protected] > Date: Mon, 30 Aug 2010 21:59:16 +0200 > To: [email protected] > Subject: Re: [mojo-dev] [Vote] [gwt] align gwt-maven releases with GWT ones > > +1 > > 2010/8/30 nicolas de loof <[email protected]>: > > Hi, > > With many API and options changes between GWT releases, the plugin gets more > > complex any time Google guys release a new SDK version. I'd like to change > > the plugin design to "align" gwt-maven to a GWT sdk release. > > The planned action are : > > > > Move trunk to a new "1.3" branch (if someone wants to support it and fix > > bugs) > > Start changes in trunk as "2.1", to be released when GWT 2.1 is final. > > Remove all dynamic artifact resolution depending on requested GWT version > > Remove support for older releases of the SDK > > Add explicit dependency on GWT 2.1 artifacts > > Support only GWT 2.1 features > > > > [ ] +1 let's do that > > [ ] 0 don't care > > [ ] -1 Please don't do that, because ... > > Nicolas > > Nicolas > > > > -- > Olivier > http://twitter.com/olamy > http://fr.linkedin.com/in/olamy > http://www.viadeo.com/fr/profile/olivier.lamy7 > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > >
