>>I plan to branch any plugin in need of db interaction for 1.1, but make >>it read 1.0 to show it starts to work from there onwards.
This was something I would like to avoid, but probably will create a branch for 0.11 and not update that code unless someone asks for bug fixes. >> Can't you use a trac version check like so: >> >> from trac import __version__ as trac_version >> if trac_version < '0.13dev': >> # Do it the old way. I would like to use the decorator syntax, and this is not something you can tie up inside a function that every other piece of code needing db acces leverages. At least, I can't do it in such a way :D >>You may want to have a look at >>[12069]:[12077], where exactly the same thing has been done for TagsPlugin. >>Feel free to query about implementation details. I took me about a week >>to get it right, and I'm willing to share my findings. You have the >>opportunity for speeding up your own work by speaking about your >>difficulties here. Will do, thanks! >>Systems still running a 0.11 version probably also don't upgrade plugins at all, as upgrading plugins can be as dangerous as >>upgrading core (which is BTW very smooth - no real issues for me since first 0.11 version). Not sure whether this is always true generally speaking. For example, we have several multiple-projects Trac installations and although we do upgrade plugins on a per-project basis when needed, the IT staff, which is responsible for the actual Trac installations, does not upgrade them (at all...). >From time to time, as new Trac releases come out, they create new Trac installations with the latest versione, for use with the new projects. Anyway, I'll do as said above. Branch for 0.11 and keep releasing fixes on it, but not new features. I'll use the latest 0.12-compatible stuff for the main stream. And keep asking for help here ;-) Thanks all. Ciao, Roberto 2012/10/3 Dirk Stöcker <[email protected]> > On Wed, 3 Oct 2012, Roberto Longobardi wrote: > > My difficulties are mainly tied to the new database API and trying to >> support with just one codebase the 0.11, 0.12 and 1.0 releases. >> > > Actually from my point of view that is wasted time - Simply use new > features when required. > > For spam-filter I constantly move to the newest version whenever I need a > new feature, otherwise stick by the older one. I only develop the newest > one. If there appears to be a major bug in old code and users request it, I > probably would release a bug fix, but till now that was never requested. > > Whoever wants to use newer version of your plugin needs to upgrade Trac. I > see no harm in that. I use that mechanism for other software as well and it > works well as long as the releases are stable, which is true for Trac. > > Systems still running a 0.11 version probably also don't upgrade plugins > at all, as upgrading plugins can be as dangerous as upgrading core (which > is BTW very smooth - no real issues for me since first 0.11 version). > > P.S. One of the ways to split code is to use "svn copy" into a new > directory like "0.11". > > Ciao > -- > http://www.dstoecker.eu/ (PGP key available) > > > -- > You received this message because you are subscribed to the Google Groups > "Trac Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to trac-dev+unsubscribe@** > googlegroups.com <trac-dev%[email protected]>. > For more options, visit this group at http://groups.google.com/** > group/trac-dev?hl=en <http://groups.google.com/group/trac-dev?hl=en>. > > -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
