releasing forrest 0.7.1 (Re: Releasing plugins (Re: svn commit: r358073 - /forrest/branches/forrest_07_branch/plugins/org.apache.forrest.plugin.input.simplifiedDocbook/resources/stylesheets/sdocbook2document.xsl))

[Johannes Schaefer <jo...@uidesign.de>]

I was wondering if updates to released versions get "built"
and result in a new "binary" to download.

I do *not* mean plugins here (see discussion below),
I mean changes to forrest core.

Other OO projects do so, e.g. if there is a security issue
(e.g. Firefox 1.0.7, then 1.5).

When should such an update be done?
For critical bugs? After each "minor" comitt (like mine today)?

Johannes


Ross Gardler schrieb:
> Johannes Schaefer wrote:
> 
>> Ross Gardler schrieb:
>>
>>> Johannes Schaefer wrote:
>>>
>>>
>>>> Do these changes get back to the downloadable version?
>>>>  http://forrest.apache.org/mirrors.cgi#closest
>>>
>>>
>>>
>>> First of all, the plugins are not downloaded via the mirrors (this is
>>> something that we need to address at some point, but this is not too
>>> urgent since the plugins are typically very small).
>>>
>>> Secondly, plugins have a different release cycle from Forrest core. So
>>> these changes will only make it into the distributed version when we
>>> make a release of the plugin.
>>
>>
>>
>> Just to understand: if I'll break forrest 0.7 with a change to some
>> plugin I'll need to create a new version of it?
> 
> 
> I just added the following FAQ response to [1] (documenting as I go):
> 
> What if a new feature breaks compatability with a released version of
> Forrest?
> ------------------------------------------------------------------------------
> 
> 
> If you add a feature to a plugin that will break compatability with a
> released version of Forrest then you should up the forrest version
> number in the plugins build.xml file. This will prevent the new version
> of the plugin being made avialble to the older version of
> Forrest.
> 
> However, you might light to consider doing a release of the plugin
> before you break compatability. It depends on what other changes there
> are to the plugin before you start your work. It is always best to raise
> this on the dev list.
> 
> 
>>> How do we make a release? We're still in the process of specifying this.
>>> However, it will be essentially the same as a release for core, i.e.
>>> someone proposes it for a release, we vote, we release or not according
>>> to the vote.
>>
>>
>>
>> I've seen some of the discussion.
>> We'll need to relate the plugins to (released) versions of forrest.
> 
> 
> That is already done (see forrest version number in plugins build.xml)
> 
>>> However, it can still be used without a release. Let me explain.
>>>
>>> The current version of SVN head doesn't use plugins in-place yet. But
>>> what it does do is deploy the plugins from local src directories if they
>>> are not currently installed and no version number is provided for the
>>> plugin in forrest.properties.
>>>
>>> In addition, we can release unversioned copies of the plugin, which will
>>> then be installed to those users without the src. However, this is the
>>> part of the release process we have not yet fully worked out.
>>>
>>> So, what do you want to achieve? Continue the discussion down whichever
>>> of the above avenues you need to, lets work out the relevant process.
>>
>>
>>
>> We use forrest at customer's sites and I simply would like to point
>> them to the download page and say: get the latest release (update).
>> It's hard talking them into svn and stuff :-)
> 
> 
> If no vbersion number is supplied Forrest will always, automatically,
> download the most recent version of the plugin for the version of
> Forrest being run.
> 
> However, you should be aware that this may be a development version as
> things currently stand. I have been thinking of changing the behaviour
> slightly, so that if no version is specified the most recent *released*
> version is installed, if "-dev" is specified then the most recent
> development version is specified.
> 
> There is no need for the user to download anything. Forrest will do that
> automatically (unless there is an issue with write permissions or proxies).
> 
>> So, are the updates to the released forrest-0.7 brought back to the
>> binary distribution at http://forrest.apache.org/mirrors.cgi ?
>>
>> As far as I see: No.
> 
> 
> No, as I said before, the plugins are not mirrored. They are only
> available from the plugin download site [2], Forrest *automatically*
> retrieves them from there (but note, they are not upgraded
> automatically, the user has to delete the installed plugins for the
> upgrade to occur - another todo item [3]).
> 
> To get plugins onto the plugin site it must be deployed. However, when
> and how we can do this has not yet been fully agreed.
> 
> I just changed the plugin build system slightly. It is now possible to
> deploy a plugin or to release it. Deploying only uploads the
> unversioned, i.e. development, copy to the download server. Releasing
> uploads a versioned copy.
> 
> This means that you can now safely do "ant deploy" for the docbook plugin.
> 
> You update will be used by 0.7 Forrest (assuming that you have not
> broken backward compatability and therefore not updated the minimum
> Forrest version number). To have your clients update all they need to do
> is delete FORREST_HOME/build/plugins/PLUGIN_NAME and run Forrest as normal.
> 
> I hope this is getting clearer to us all, me included ;-)

yes, much clearer.
Will pose another question in new thread.
js

> 
> Ross
> 
> [1]
> http://svn.apache.org/repos/asf/forrest/trunk/plugins/RELEASE_PROCESS.txt
> [2] http://forrest.apache.org/plugins/
> [3] http://issues.apache.org/jira/browse/FOR-343
> 


-- 
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax  +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 *
D-81825 München
www.uidesign.de

Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de

when to make a release of a branch

[David Crossley <cr...@apache.org>]

Ross Gardler wrote:
> Johannes Schaefer wrote:
> >I was wondering if updates to released versions get "built"
> >and result in a new "binary" to download.
> >
> >I do *not* mean plugins here (see discussion below),
> >I mean changes to forrest core.
> 
> Ahhhh... I musinderstood.
> 
> >Other OO projects do so, e.g. if there is a security issue
> >(e.g. Firefox 1.0.7, then 1.5).
> 
> Yes, the key point is thet there needs to be a compelling reason to do 
> it. There is considerable effort involved with doing a release it is not 
> simply a case of packaging and making it available for download.

Yes, big effort. It also needs the full testing
and vote process and co-operation of the PMC.
It would not be as bad as doing a major release
(e.g. 0.8) but still a lot of effort. [1] [2]

> >When should such an update be done?
> >For critical bugs? After each "minor" comitt (like mine today)?
> 
> My opinion would be critical bugs. Minor commits would wait until the 
> next "major" release.

Another reason might be that we take too long
to do the next major release, or strike a big
impediment. Like Ross, i would rather put the effort
into getting 0.8 out.

> Of course, if an individual dev has a personal/business reason for doing 
> a release and they are willing to put the effort in, it is unlikely that 
> anyone would object.

There is an alternative, if your clients cannot manange
to use svn to keep up-to-date with the branch.

If any developer (not just committer) needs to, then
they can package the product themselves. Don't call it a
product of our project. It is just some private distribution.

Just follow the procedure in [1], but build a private package
giving it a good name, e.g. forrest-0.7.1-dev-20051221-r358425.zip
There are a lot of steps that you can leave out, which should
be obvious.

Alternatively you might get away with just zipping
up the contents of your current forrest_07_branch
working copy of svn.

> However, most devs (well, only me for certain) 
> would prefer to focus on 0.8 rather than spend time on a 0.7.1 release
> 
> (unless there is a critical issue involved).

Me too. With a small project we need to focus on trunk.

[1] etc/RELEASE_PROCESS.txt
[2] http://forrest.apache.org/guidelines.html#actions

We really need to document this. I made some links to
similar email discussion:
http://forrest.apache.org/guidelines.html#develop

-David

Re: releasing forrest 0.7.1 (Re: Releasing plugins (Re: svn commit: r358073 - /forrest/branches/forrest_07_branch/plugins/org.apache.forrest.plugin.input.simplifiedDocbook/resources/stylesheets/sdocbook2document.xsl))

[Ross Gardler <rg...@apache.org>]

Johannes Schaefer wrote:
> I was wondering if updates to released versions get "built"
> and result in a new "binary" to download.
> 
> I do *not* mean plugins here (see discussion below),
> I mean changes to forrest core.

Ahhhh... I musinderstood.

> Other OO projects do so, e.g. if there is a security issue
> (e.g. Firefox 1.0.7, then 1.5).

Yes, the key point is thet there needs to be a compelling reason to do 
it. There is considerable effort involved with doing a release it is not 
simply a case of packaging and making it available for download.

> When should such an update be done?
> For critical bugs? After each "minor" comitt (like mine today)?

My opinion would be critical bugs. Minor commits would wait until the 
next "major" release.

Of course, if an individual dev has a personal/business reason for doing 
a release and they are willing to put the effort in, it is unlikely that 
anyone would object. However, most devs (well, only me for certain) 
would prefer to focus on 0.8 rather than spend time on a 0.7.1 release

(unless there is a critical issue involved).

Ross