You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2010/05/27 11:16:44 UTC
release process for our plugins
We do have a process sorted out for releasing of Forrest core.
[1] How to release Forrest
http://forrest.apache.org/procedures/release/How_to_release.html
I reckon that it meets the ASF requirements. Please see
this email where i have before tried to ensure that we do:
[2] http://markmail.org/message/kwecoaue7p4qcy2v
To: forrest-dev
Re: Clarification on the release requirements
Unfortunately the links are broken in that display,
so i tracked them down again.
Here are a couple of places where Roy set out some
principles/policy/reasons-for-doing-stuff ...
[3] http://markmail.org/message/3odlybipss4wnczl
[4] http://markmail.org/message/njray5dbazwcdcts
I reckon that it would be worth our while to review
that discussion.
There is other background material at
[5] http://www.apache.org/dev/#releases
[6] http://www.apache.org/dev/release.html
With those principles in mind, we need to attend to our
release process for our plugins.
We don't actually yet have a process.
Do "find in page" for "plugin" at [1] to see the steps.
You will reach a point where our doc says fixme
and refers to a draft document at
[7] $FORREST_HOME/plugins/RELEASE_PROCESS.txt
There are some other notes at
[8] http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
We do have tools for doing "deploy" of plugins, i.e.
putting an updated version on the server.
As described in [6] Releases FAQ,
"
What Is A Release?
Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below.
"
It should be easy. For each plugin, the proposer puts a package
at their apache.org space. We each download, install, review,
and then vote. Then use the "release" Ant target rather than
the "deploy" target.
However, we have another issue.
We have been providing that software via our website.
If i understand correctly then we should be doing
that from w.a.o/dist/forrest/
See some discussion at
https://issues.apache.org/jira/browse/FOR-1068
Perhaps we should at least solve the "release process" issue now,
and leave the deployment issue until post 0.9 release.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Gav... wrote:
> >
> > Ok, but still, I'm confused as to why 0.8 version plugins, i.e.
> > most of them, are appearing in the 0.7 and 0.9 versions of
> > the plugins page. That's what I see as broken.
>
> Ah, sorry i misread your question.
>
> Yes, i too think that there is something wrong with that
> "Plugins Index".
>
> Each is a generated page.
>
> cd site-author/build/forrest-docs
> diff pluginDocs/plugins_0_80/index.html pluginDocs/plugins_0_70/index.html
> shows that they are essentially the same.
>
> I agree that this is confusing.
We should investigate this ASAP.
Each of the three "Plugins Index" pages do
still need to be re-generated. For example,
a new plugin could be added tomorrow that
only requires 0.8 Forrest, so it would still
need to be listed on those pages.
Perhaps the pipeline that generates these pages
could consider the URI, e.g. seeing .../plugins_0_80/...
it should know not to overwrite those that have
been upgraded to now use 0.9 forrest.
Perhaps the plugins descriptor files need a "since"
attribute to assist with that.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
Gav... wrote:
>
> Ok, but still, I'm confused as to why 0.8 version plugins, i.e.
> most of them, are appearing in the 0.7 and 0.9 versions of
> the plugins page. That's what I see as broken.
Ah, sorry i misread your question.
Yes, i too think that there is something wrong with that
"Plugins Index".
Each is a generated page.
cd site-author/build/forrest-docs
diff pluginDocs/plugins_0_80/index.html pluginDocs/plugins_0_70/index.html
shows that they are essentially the same.
I agree that this is confusing.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
I want to update the "Anakia output" plugin.
Have found a much simpler way of configuring
a Forrest-using project to export all of their
site content.
So i will deploy the existing plugin once more.
Then increment its "plugin version", then make
the changes, then deploy again.
It is important that this plugin works for both
Forrest 0.8 and Forrest 0.9 versions. So i will
not be incrementing its "forrest version".
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
Gav... wrote:
> David Crossley wrote:
> > Gav... wrote:
> > >
> > > 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?
I presume that they will be stuck with whatever is currently
deployed as "forrestVersion 0.8".
> 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.
I am visualising getting conflicts that cannot be
resolved, because some plugins have been deployed since.
Also new plugins have been added, so there would be
conflicts in the "plugins descriptor" files.
> 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.
I agree.
> Afterwards, fine,
> we try and keep up and do it properly.
Lets hope so again. I hear this echo.
> 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.
People are probably clamouring to upgrade.
> 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.
I think that it is too late to deploy it.
It does have warnings to developers. People who are using it should
be developers using trunk. We probably should never have deployed
this plugin. It was in such a state of flux, that it only made
sense to be available to developers using trunk.
-David
RE: release process for our plugins
Posted by "Gav..." <ga...@16degrees.com.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...
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
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.
> > > 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.
> 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.
RE: release process for our plugins
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: David Crossley [mailto:crossley@apache.org]
> Sent: Monday, 7 June 2010 10:28 AM
> To: dev@forrest.apache.org
> Subject: Re: release process for our plugins
>
> Gav... wrote:
> > David Crossley wrote:
> > >
> > > It should be easy to whip around each plugin and
> > > do a proper release of each.
> > >
> > > That also means that each plugin has a specific marked
> > > version, rather than just a continual work-in-progress.
> >
> > OK, when updating documentation for a plugin, all we need to is do
> > an 'ant deploy' on the plugin.
>
> No. If only docs have changed then '... ant deploy-docs'.
ah ok great, I missed that option.
>
> > 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?
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.
>
> > What happens to the older versions of the plugins ? The plugins
> system seems
> > a bit
> > broken currently, doesn't matter what forrest version you choose when
> > looking
> > at the plugins page, it shows the same plugin versions in all version
> tabs.
>
> The system isn't broken. It is just that people maintaining
> the plugins have not handled them properly.
>
> For example, the pdf plugin was updated and requires v0.9 but
> has not had its "forrestVersion" incremented. Nor was it
> deployed for 0.8 before making changes that require 0.9 version.
> See FOR-1187.
>
> Similarly with the Dispatcher. It still says forrestVersion 0.8
Ok, but still, I'm confused as to why 0.8 version plugins, i.e.
most of them, are appearing in the 0.7 and 0.9 versions of
the plugins page. That's what I see as broken.
>
> > 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.
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. (?)
Any more tweaks I make to those docs I'll just do a ant deploy-docs on them.
Gav...
>
> -David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Gav... wrote:
> > David Crossley wrote:
> > >
> > > It should be easy to whip around each plugin and
> > > do a proper release of each.
> > >
> > > That also means that each plugin has a specific marked
> > > version, rather than just a continual work-in-progress.
> >
> > OK, when updating documentation for a plugin, all we need to is do
> > an 'ant deploy' on the plugin.
>
> No. If only docs have changed then '... ant deploy-docs'.
>
> > 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.
>
> > What happens to the older versions of the plugins ? The plugins system seems
> > a bit
> > broken currently, doesn't matter what forrest version you choose when
> > looking
> > at the plugins page, it shows the same plugin versions in all version tabs.
>
> The system isn't broken. It is just that people maintaining
> the plugins have not handled them properly.
>
> For example, the pdf plugin was updated and requires v0.9 but
> has not had its "forrestVersion" incremented. Nor was it
> deployed for 0.8 before making changes that require 0.9 version.
> See FOR-1187.
>
> Similarly with the Dispatcher. It still says forrestVersion 0.8
>
> > 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.
>
> Please see the explanation at
> http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
Another key point is that the "plugin" user-end system
will look in 0.9 space if that is what they are using.
Not finding a plugin there (because that plugin did
not require 0.9) it would fall back to the 0.8 version
(which is also the default one at the top-level of the
plugins distribution tree.
The docs explain it better.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
Gav... wrote:
> David Crossley wrote:
> >
> > It should be easy to whip around each plugin and
> > do a proper release of each.
> >
> > That also means that each plugin has a specific marked
> > version, rather than just a continual work-in-progress.
>
> OK, when updating documentation for a plugin, all we need to is do
> an 'ant deploy' on the plugin.
No. If only docs have changed then '... ant deploy-docs'.
> 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.
> What happens to the older versions of the plugins ? The plugins system seems
> a bit
> broken currently, doesn't matter what forrest version you choose when
> looking
> at the plugins page, it shows the same plugin versions in all version tabs.
The system isn't broken. It is just that people maintaining
the plugins have not handled them properly.
For example, the pdf plugin was updated and requires v0.9 but
has not had its "forrestVersion" incremented. Nor was it
deployed for 0.8 before making changes that require 0.9 version.
See FOR-1187.
Similarly with the Dispatcher. It still says forrestVersion 0.8
> 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.
Please see the explanation at
http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
-David
RE: release process for our plugins
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: David Crossley [mailto:crossley@apache.org]
> Sent: Friday, 4 June 2010 12:50 PM
> To: dev@forrest.apache.org
> Subject: Re: release process for our plugins
>
> Gav... wrote:
> > David Crossley wrote:
> > >
> > > One very important reason for designing the plugin system
> > > the way that we did, was to ensure that each plugin has
> > > its own community supporting it.
> >
> > That doesn't seem to be the case to me at the moment, ...
>
> That is one reason that i raised this issue again. We knew
> in the past that we had not properly followed a separate
> release cycle for each plugin.
>
> > ... when core forrest devs
> > want to do a release, we need to ensure all plugins work, at least I
> see
> > that as the current situation.
>
> That is different, and we would do that regardless of the
> plugins each being released separately.
>
> It should be easy to whip around each plugin and
> do a proper release of each.
>
> That also means that each plugin has a specific marked
> version, rather than just a continual work-in-progress.
OK, when updating documentation for a plugin, all we need to is do
an 'ant deploy' on the plugin.
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 ?
What happens to the older versions of the plugins ? The plugins system seems
a bit
broken currently, doesn't matter what forrest version you choose when
looking
at the plugins page, it shows the same plugin versions in all version tabs.
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)
Thanks
Gav...
>
> -David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
Gav... wrote:
> David Crossley wrote:
> >
> > One very important reason for designing the plugin system
> > the way that we did, was to ensure that each plugin has
> > its own community supporting it.
>
> That doesn't seem to be the case to me at the moment, ...
That is one reason that i raised this issue again. We knew
in the past that we had not properly followed a separate
release cycle for each plugin.
> ... when core forrest devs
> want to do a release, we need to ensure all plugins work, at least I see
> that as the current situation.
That is different, and we would do that regardless of the
plugins each being released separately.
It should be easy to whip around each plugin and
do a proper release of each.
That also means that each plugin has a specific marked
version, rather than just a continual work-in-progress.
-David
RE: release process for our plugins
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: David Crossley [mailto:crossley@apache.org]
> Sent: Friday, 4 June 2010 11:00 AM
> To: dev@forrest.apache.org
> Subject: Re: release process for our plugins
>
> One very important reason for designing the plugin system
> the way that we did, was to ensure that each plugin has
> its own community supporting it.
>
> -David
That doesn't seem to be the case to me at the moment, when core forrest devs
want to do a release, we need to ensure all plugins work, at least I see
that as the current situation.
Gav...
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
One very important reason for designing the plugin system
the way that we did, was to ensure that each plugin has
its own community supporting it.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Tim Williams wrote:
>
> > The draft
> > release doc in the plugins directory suggests that its possible to
> > release plugins independent of the core but couldn't we, for now, just
> > as well continue to do what we do and release the plugins with the
> > core?
>
> Ah, but it sounds like you are misunderstanding.
> we only release the PDF plugin with the core.
>
> For the rest we direct the user to our website to get additional
> software.
If changing our method to delivering the plugins as source along
with the "core" release, then this would confuse our deployment
system for plugins.
http://forrest.apache.org/docs/plugins/usingPlugins.html#sources
"Forrest will try and retrieve a plugin from local source files
first, if that fails it will look on a remote distribution server."
So the user would never receive an updated version of a plugin.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> David Crossley wrote:
> >
> The "release process" issue? relative to plugins I assume?
Yep, as i said, i reckon that our core releae process is fine.
Just the release process for each plugin needs attention.
> The draft
> release doc in the plugins directory suggests that its possible to
> release plugins independent of the core but couldn't we, for now, just
> as well continue to do what we do and release the plugins with the
> core?
Ah, but it sounds like you are misunderstanding.
we only release the PDF plugin with the core.
For the rest we direct the user to our website to get additional
software.
This is the problem.
However, good point that you raise. We could just change our
approach and deliver all plugins with the core.
Would we need to change our process for local deployment
of plugins? Still enabling developers to operate as
efficiently as they do now.
There was a reason for keeping it separate.
Anyway, this might get us over the initial hurdle.
> In other words, it seems to me we're meeting Roy's intent
> fairly well by releasing the whole bundle together - formal process,
> signed, etc.
And meeting the distribution location requirements.
The source release and everything required to build it
is released there.
Additional convenience packages, such as our released plugins
could then be provided elsewhere.
> I guess, what I'm wondering is... can we punt on plugin releases, move
> dispatcher to /plugins and just vote on the whole bundle as normal?
See above, that is not normal, but might be a solution for this time.
-David
> Or, do you see something that needs addressing now, before a 0.9
> release? Sorry, you were probably hoping for answers not questions:)
>
> --tim
RE: release process for our plugins
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Tim Williams [mailto:williamstw@gmail.com]
> Sent: Friday, 28 May 2010 12:20 AM
> To: dev@forrest.apache.org
> Subject: Re: release process for our plugins
>
> On Thu, May 27, 2010 at 5:16 AM, David Crossley <cr...@apache.org>
> wrote:
> > We do have a process sorted out for releasing of Forrest core.
> > [1] How to release Forrest
> > http://forrest.apache.org/procedures/release/How_to_release.html
> >
> > I reckon that it meets the ASF requirements. Please see
> > this email where i have before tried to ensure that we do:
> > [2] http://markmail.org/message/kwecoaue7p4qcy2v
> > To: forrest-dev
> > Re: Clarification on the release requirements
> >
> > Unfortunately the links are broken in that display,
> > so i tracked them down again.
> >
> > Here are a couple of places where Roy set out some
> > principles/policy/reasons-for-doing-stuff ...
> > [3] http://markmail.org/message/3odlybipss4wnczl
> > [4] http://markmail.org/message/njray5dbazwcdcts
> >
> > I reckon that it would be worth our while to review
> > that discussion.
> >
> > There is other background material at
> > [5] http://www.apache.org/dev/#releases
> > [6] http://www.apache.org/dev/release.html
> >
> > With those principles in mind, we need to attend to our
> > release process for our plugins.
> >
> > We don't actually yet have a process.
> >
> > Do "find in page" for "plugin" at [1] to see the steps.
> > You will reach a point where our doc says fixme
> > and refers to a draft document at
> > [7] $FORREST_HOME/plugins/RELEASE_PROCESS.txt
> > There are some other notes at
> > [8] http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
> >
> > We do have tools for doing "deploy" of plugins, i.e.
> > putting an updated version on the server.
> >
> > As described in [6] Releases FAQ,
> > "
> > What Is A Release?
> > Releases are, by definition, anything that is published beyond the
> group that owns it. In our case, that means any publication outside the
> group of people on the product dev list. If the general public is being
> instructed to download a package, then that package has been released.
> Each PMC must obey the ASF requirements on approving any release. How
> you label the package is a secondary issue, described below.
> > "
> >
> > It should be easy. For each plugin, the proposer puts a package
> > at their apache.org space. We each download, install, review,
> > and then vote. Then use the "release" Ant target rather than
> > the "deploy" target.
> >
> > However, we have another issue.
> >
> > We have been providing that software via our website.
> > If i understand correctly then we should be doing
> > that from w.a.o/dist/forrest/
> >
> > See some discussion at
> > https://issues.apache.org/jira/browse/FOR-1068
> >
> > Perhaps we should at least solve the "release process" issue now,
> > and leave the deployment issue until post 0.9 release.
>
> The "release process" issue? relative to plugins I assume? The draft
> release doc in the plugins directory suggests that its possible to
> release plugins independent of the core but couldn't we, for now, just
> as well continue to do what we do and release the plugins with the
> core? In other words, it seems to me we're meeting Roy's intent
> fairly well by releasing the whole bundle together - formal process,
> signed, etc.
>
> I guess, what I'm wondering is... can we punt on plugin releases, move
> dispatcher to /plugins and just vote on the whole bundle as normal?
> Or, do you see something that needs addressing now, before a 0.9
> release? Sorry, you were probably hoping for answers not questions:)
To me, a plugin means an add-on, in addition to, extra. However some of our
'plugins' are in fact required if Forrest is to be useful. Anyway,
The plugins (not whiteboard plugins) I think as you say, we could bundle
this
time around, it also shows that the plugin versions we bundle are guaranteed
to work with that Forrest release.
If this was somewhere else, where folks create plugins and work on them
alone
and maintain them alone independent of Forrest, then it would be easier, but
we
don't and it seems every plugin we have has to be maintained by forrest devs
in addition to the core in order to get a release out. That seems wrong to
me,
it gets harder each time as we accumulate more plugins. So that means I
guess I'd rather plugins be done separately of a core Forrest release in the
future - if a plugin doesn't keep up, so be it I guess until someone wants
to take on maintaining it.
For this time, to get a release done quickly, I'm ok with doing what we have
always
done, as long as meets with guidelines.
Gav...
>
> --tim
Re: release process for our plugins
Posted by Tim Williams <wi...@gmail.com>.
On Thu, May 27, 2010 at 5:16 AM, David Crossley <cr...@apache.org> wrote:
> We do have a process sorted out for releasing of Forrest core.
> [1] How to release Forrest
> http://forrest.apache.org/procedures/release/How_to_release.html
>
> I reckon that it meets the ASF requirements. Please see
> this email where i have before tried to ensure that we do:
> [2] http://markmail.org/message/kwecoaue7p4qcy2v
> To: forrest-dev
> Re: Clarification on the release requirements
>
> Unfortunately the links are broken in that display,
> so i tracked them down again.
>
> Here are a couple of places where Roy set out some
> principles/policy/reasons-for-doing-stuff ...
> [3] http://markmail.org/message/3odlybipss4wnczl
> [4] http://markmail.org/message/njray5dbazwcdcts
>
> I reckon that it would be worth our while to review
> that discussion.
>
> There is other background material at
> [5] http://www.apache.org/dev/#releases
> [6] http://www.apache.org/dev/release.html
>
> With those principles in mind, we need to attend to our
> release process for our plugins.
>
> We don't actually yet have a process.
>
> Do "find in page" for "plugin" at [1] to see the steps.
> You will reach a point where our doc says fixme
> and refers to a draft document at
> [7] $FORREST_HOME/plugins/RELEASE_PROCESS.txt
> There are some other notes at
> [8] http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
>
> We do have tools for doing "deploy" of plugins, i.e.
> putting an updated version on the server.
>
> As described in [6] Releases FAQ,
> "
> What Is A Release?
> Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below.
> "
>
> It should be easy. For each plugin, the proposer puts a package
> at their apache.org space. We each download, install, review,
> and then vote. Then use the "release" Ant target rather than
> the "deploy" target.
>
> However, we have another issue.
>
> We have been providing that software via our website.
> If i understand correctly then we should be doing
> that from w.a.o/dist/forrest/
>
> See some discussion at
> https://issues.apache.org/jira/browse/FOR-1068
>
> Perhaps we should at least solve the "release process" issue now,
> and leave the deployment issue until post 0.9 release.
The "release process" issue? relative to plugins I assume? The draft
release doc in the plugins directory suggests that its possible to
release plugins independent of the core but couldn't we, for now, just
as well continue to do what we do and release the plugins with the
core? In other words, it seems to me we're meeting Roy's intent
fairly well by releasing the whole bundle together - formal process,
signed, etc.
I guess, what I'm wondering is... can we punt on plugin releases, move
dispatcher to /plugins and just vote on the whole bundle as normal?
Or, do you see something that needs addressing now, before a 0.9
release? Sorry, you were probably hoping for answers not questions:)
--tim
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
I am going to take the opportunity before we do deployment
of plugins, to tweak the presentation of plugin websites.
Don't let that stop you guys from getting your favourite
plugin ready.
-David
RE: release process for our plugins
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: David Crossley [mailto:crossley@apache.org]
> Sent: Saturday, 3 July 2010 7:18 PM
> To: dev@forrest.apache.org
> Subject: Re: release process for our plugins
>
> David Crossley wrote:
> > David Crossley wrote:
> > > I have been doing some more review, and will attempt to
> > > present a proposal soon.
> >
> > Still :-)
> >
> > > --------------
> > > The following do not have an entry in the plugins
> > > descriptor file whiteboard-plugins.xml and have never
> > > been deployed to the website ...
> > > Database, OpenOffice.org-output, Blog, Lenya,
> > > DevTools, GoogleSitemap, rtf-output
> > >
> > > --------------
> > > The following do have an entry in the plugins
> > > descriptor file whiteboard-plugins.xml
> > > However they have never been deployed to the website
> > > which probably creates confusion ...
> > > Resume, XDoc, baetle, doac, ecs, foaf, skos, input.tei,
> > > NoteTaking, xhtml2, output.OOo, iCal, output.tei
> > >
> > > Some of those might not be relevant to deploy yet,
> > > but some are probably okay.
> >
> > I found a useful-looking attribute while browsing
> > the plugin build.xml files.
> > <!-- The plugin will only appear in the plugins list if publish =
> true
> > <property name="publish" value="true"/> -->
> >
> > If they are not ready enough to even have an
> > initial deployment then we can list them differently.
> > So people can still know about them and get interested.
>
> I have finished the work with presenting plugins
> in the plugin lists.
> See http://forrest.apache.org/pluginDocs/
>
> Also done a review and synchronisation of the configuration
> aspects of all plugins.
> See $FORREST_HOME/etc/review-plugin-deployment.txt
That looked like tricky work and the end result is excellent,
thanks for doing all that, great stuff!
Gav...
>
> Still working on a proposal for getting many plugins
> out of the whiteboard and properly deployed.
>
> Don't let that hold anyone up from working on the
> Forrest release. With our current release process,
> plugins have a separate release cycle to the core.
>
> -David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> David Crossley wrote:
> > I have been doing some more review, and will attempt to
> > present a proposal soon.
>
> Still :-)
>
> > --------------
> > The following do not have an entry in the plugins
> > descriptor file whiteboard-plugins.xml and have never
> > been deployed to the website ...
> > Database, OpenOffice.org-output, Blog, Lenya,
> > DevTools, GoogleSitemap, rtf-output
> >
> > --------------
> > The following do have an entry in the plugins
> > descriptor file whiteboard-plugins.xml
> > However they have never been deployed to the website
> > which probably creates confusion ...
> > Resume, XDoc, baetle, doac, ecs, foaf, skos, input.tei,
> > NoteTaking, xhtml2, output.OOo, iCal, output.tei
> >
> > Some of those might not be relevant to deploy yet,
> > but some are probably okay.
>
> I found a useful-looking attribute while browsing
> the plugin build.xml files.
> <!-- The plugin will only appear in the plugins list if publish = true
> <property name="publish" value="true"/> -->
>
> If they are not ready enough to even have an
> initial deployment then we can list them differently.
> So people can still know about them and get interested.
I have finished the work with presenting plugins
in the plugin lists.
See http://forrest.apache.org/pluginDocs/
Also done a review and synchronisation of the configuration
aspects of all plugins.
See $FORREST_HOME/etc/review-plugin-deployment.txt
Still working on a proposal for getting many plugins
out of the whiteboard and properly deployed.
Don't let that hold anyone up from working on the
Forrest release. With our current release process,
plugins have a separate release cycle to the core.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> I have been doing some more review, and will attempt to
> present a proposal soon.
Still :-)
> --------------
> The following do not have an entry in the plugins
> descriptor file whiteboard-plugins.xml and have never
> been deployed to the website ...
> Database, OpenOffice.org-output, Blog, Lenya,
> DevTools, GoogleSitemap, rtf-output
>
> --------------
> The following do have an entry in the plugins
> descriptor file whiteboard-plugins.xml
> However they have never been deployed to the website
> which probably creates confusion ...
> Resume, XDoc, baetle, doac, ecs, foaf, skos, input.tei,
> NoteTaking, xhtml2, output.OOo, iCal, output.tei
>
> Some of those might not be relevant to deploy yet,
> but some are probably okay.
I found a useful-looking attribute while browsing
the plugin build.xml files.
<!-- The plugin will only appear in the plugins list if publish = true
<property name="publish" value="true"/> -->
If they are not ready enough to even have an
initial deployment then we can list them differently.
So people can still know about them and get interested.
-David
Re: release process for our plugins
Posted by David Crossley <cr...@apache.org>.
I have been doing some more review, and will attempt to
present a proposal soon.
We have 12 plugins, and 34 whiteboard plugins.
--------------
The situation with Java code ...
With the core plugins, only one has Java code: PhotoGallery.
With the whiteboard plugins, only six have Java code:
Database, Resume, DevTools, dispatcher, solr, xhtml2.
--------------
The situation with Locationmap ...
Just before the 0.8 release we reviewed all core plugins
to use the Locationmap.
However only some whiteboard plugins were enhanced to
use Locationmap (22 out of 34).
--------------
The situation with forrestVersion number for plugins ...
All core plugins are at version 0.8
With whiteboard plugins, four are at version 0.7
and of course none of those use Locationmap.
There are seven saying that they need 0.9 (i will
investigate further). The other 23 are at version 0.8
--------------
The following do not have an entry in the plugins
descriptor file whiteboard-plugins.xml and have never
been deployed to the website ...
Database, OpenOffice.org-output, Blog, Lenya,
DevTools, GoogleSitemap, rtf-output
--------------
The following do have an entry in the plugins
descriptor file whiteboard-plugins.xml
However they have never been deployed to the website
which probably creates confusion ...
Resume, XDoc, baetle, doac, ecs, foaf, skos, input.tei,
NoteTaking, xhtml2, output.OOo, iCal, output.tei
Some of those might not be relevant to deploy yet,
but some are probably okay.
--------------
So that is a summary. I will try to get on with a
proposal about a deployment and release process.
-David