Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Gav..." <gavin@16degrees.com.au>
To: <dev@forrest.apache.org>
References: <20100527091644.GC54036@igg.local>
 <20100604010028.GB20607@igg.local> <008201cb0384$b2d326e0$187974a0$@com.au>
 <20100604024933.GC20607@igg.local> <012b01cb0567$acb9f6f0$062de4d0$@com.au>
 <20100607002740.GD40649@igg.local> <01ac01cb05db$11d01f60$35705e20$@com.au>
 <20100607020534.GH40649@igg.local>
In-Reply-To: <20100607020534.GH40649@igg.local>
Subject: RE: release process for our plugins
Date: Mon, 7 Jun 2010 12:38:31 +1000
Message-ID: <01af01cb05ea$852fa750$8f8ef5f0$@com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcsF5gEkxXWzxiCVRlulgFBjDUnRpQAAXDHw
Content-Language: en-au


> -----Original Message-----
> From: David Crossley [mailto:crossley@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...