-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03.10.2012 20:51, Roberto Longobardi wrote:
> OK.
> 
> Well, TracUsers' data is a bit outdated (174 entries out of 200 were not
> updated during 2012), so the fact that most of it shows 0.11 as the
> latest used release (95 out of 200) is probably not a valid guess.
- From the change history you'll see, that this is a long-running task and
constant struggle. You're welcome to dedicate some time on your own, if
you can afford it, to help with updates. In fact it should be much
easier now with the "links to Trac instances alone"- policy enforced
rather strictly.

- From my own experience Trac installation are a typical case of
setup-and-forget applications. Great for admins, bad for penetration of
new versions - arguable a majority sticks to the version they've got in
a "never touch a running system"- attitude. So personally I think, that
it's not only the best insight on current use you can get now, it even
does reflect the true share of different version out there despite of
more regular monitoring.

> Anyway, we ourselves still have a mixed 0.11 and 0.12 installation base,
> and trac-hacks itself is struggling to upgrade from even 0.10... so I
> was guessing 0.11 would still be pretty present out there.
Think so too as stated earlier.

> 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.
> 
> In order to keep 0.11 support, I didn't use the decorators syntax so
> far, but some code[1] that checks for availability of a particular API
> and uses that.
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. 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 don't want to branch the code to be able to support 1.0, so I would
> either find some way of supporting every version with a common (dynamic)
> syntax, or be forced to drop 0.11.
Your choice. I found it possible to support 0.11 - 1.0, but it's
certainly not an easy task.

> At the same time, I want to replace my proprietary self-db-version
> checking code with the Trac standard one.
> 
> In addition to that, I have rollbacks inside exception handling code,
> even in read-only functions, but with some patience this is easily fixed.
Sure, I think this is important. 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.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBslHoACgkQ31DJeiZFuHfgDwCcCoervymIPjfRJlG0z33vTXlM
P1MAnAtJy6uTWUmO0CYVcPCxGWHHWGQQ
=2aCR
-----END PGP SIGNATURE-----

-- 
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.

Reply via email to