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
