sp<number> will be easy not sure when the test harness will be ready :P
2010/9/2 Robert Scholte <[email protected]> > +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 > > > > > > > >
