> -----Original Message----- > From: David Crossley [mailto:cross...@apache.org] > Sent: Monday, 7 June 2010 12:06 PM > To: dev@forrest.apache.org > Subject: Re: release process for our plugins > > Gav... wrote: > > David Crossley wrote: > > > Gav... wrote: > > > > > > > > When code has been changed on a plugin since the last release, > are we > > > using > > > > the > > > > policy of 'lets upgrade the forrest version required as well as > the > > > plugin > > > > version number' - that would make it easier all round. If that is > ok, > > > then I > > > > can > > > > just go round all plugins that have had any code changes since > April > > > 2007 > > > > and bump > > > > their forrest version numbers to 0.9 ? > > > > > > No. We are not using that policy. > > > > > > The "forrestVersion" only gets incremented if there are > > > changes that "require" the current version of Forrest. > > > > > > To do what you are suggesting would mean that users of the > > > released versions of Forrest would not get any plugin updates. > > > > Ok, but the plugins when rebuilt will be done so with Java 1.5 , how > > will that affect things? > > Ah good point. We should have done a deploy of all > plugins that had Java code (only some do) before > doing that change. > > To answer, i don't know what effect it will have. > > > It's been so long since some were updated that I guess they would > need > > testing on 0.8 release before deciding if they are still compatible > or > > not. > > This is part of our past problems. We don't deploy those > plugins often enough and don't pay sufficent attention > to their version numbers. > > Hmmm, i don't know what to do.
Ok, what I was sort of suggesting before, was that we bump all forrestversions of all plugins to 0.9 (or 0.9-dev ?) and do ant deploy on them all. (not an ant release which can be done at our leisure later?). This will bring us up to date. Doing the above, will that remove all plugins from being available to 0.8 users or not? If not we're fine, if yes then perhaps we should do a final release of all 0.8 plugins and do so from the versions of the plugins we have in the 0.8 tag we did at release time. Any changes after that will as above go into the 0.9 version. I realise you said we should only bump the forrestversion only if 0.9 functionality is introduced, but I'm suggesting this as a once off opportunity to catch up, it would be too time consuming to back and check every plugin at this stage, and being so close to a new 0.9 Forrest (core) release we really do need to catch up. Afterwards, fine, we try and keep up and do it properly. This is pre 1.0 stable after all and folks should be encouraged to upgrade, we can not guarantee backwards compatability and we don't have any policy of back-porting. Another thing to mention here, the 'dispatcher' plugin we so want out of the whiteboard, impossible if we don't bring it up to date -- in terms of documentation it is shocking, still mentions of <forrest:views.../> all over the place as well as *.fv config files which are superseded now after the dispatcher rewrite 6 months ago. I'd love to start updating the documentation for the dispatcher plugin but I'm stuck because we need to deploy it first -- your mention of deploy-docs, I could start using that, but not until it's at a 0.9 version I don't think. > > > > > Obviously any 'plugin releases' between forrest versions can just > > > have their > > > > 'plugin > > > > version' bumped - and for any of these we intend to start voting > on? > > > (After > > > > this > > > > next Forrest release if I'm interpreting correctly) > > > > > > Again only if it "requires" v0.9 functionality. > > > > huh, Im talking 'plugin version' such as 0.1, 0.2, 0.3 not the > > 'forrest version' > > > > But I get it now I think, any total code changes that warrant a new > > plugin version number, such as any release would. Minor code changes > > whould stay at the same version number until there are sufficient to > > warrant a bump in number (i.e release) - And, if any of those code > > changes introduce 0.9 specific functionality, then we bump the > 'forrest > > version' also. Therefore it is assumed the 'forrest version' number > is > > the _minimum_ version we are saying it _will_ work on. > > > > > Please see the explanation at > > > http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html > > > > Oh, how I've read that a million times these last couple of days. > > Yeah, i understand. There are also some past dev discussions > where Ross explained it. Also there are some JIRA tickets. Yep, I've been looking. Of particular interest is to me is this one: https://issues.apache.org/jira/browse/FOR-1080 I have done this for the POD plugin docs. There is an additional section at the bottom of : http://forrest.apache.org/pluginDocs/plugins_0_90/org.apache.forrest.plugin. output.POD/ which points to the dispatcher plugin docs 'examples' section, with a POD example in place on that page. The idea here is that all dispatcher enabled plugins have a similar blurb that I added to the POD plugin docs which just points to the dispatcher examples section. That way, whenever we add example docs for any plugin, we can do it all in one place - the dispatcher plugin, rather than have to update each separate plugin with new docs, this makes particular sense if there is a dispatcher change that affects all plugins, which so far has been the case quite often. > > > I have just updated the POD plugin - it had code changes from 2 years > > ago, + doc changes and references dispatcher related documentation > > examples that are or will be 0.9 specific, so I hope I was right in > > bumping both the 'forrest version' and 'plugin version' in this case. > (?) > > Bringing my comment over from that edit to try to > keep the discussion together. > http://thread.gmane.org/gmane.text.xml.forrest.cvs/9889/focus=27975 > > > > Sure it may have been updated, but if its own functionality > > did not substantially change then leave its ""plugin-version" as-is. > > > > Did it require new "0.9" functionalty, If so then also > > increment its "forrest.version". > > > > By the way would need to also happen in the Plugins descriptor file > > e.g. plugins/plugins.xml etc. Ok, so having bumped the version of POD plugin t0 0.2->0.3 and 0.8->0.9 are we all ok with my updating the plugins.xml to reflect the same? Sometime soon, we need to sort out those versioned plugin pages to only show the versions of the plugins that they are meant to. I'm sure that's harder than it sounds. Gav...
