Trac version usage statistics

[Roberto Longobardi]

Hi all,

facing the difficulties in making my plugins compatible with Trac 1.0 I'm thinking whether to drop support for Trac 0.11 at least.

Is there anywhere a usage statistics figure telling how much each Trac version is used?

If not, may we suggest a poll?

Thanks, ciao.

Roberto

[Christian Boos]

On 10/3/2012 5:37 PM, Roberto Longobardi wrote:
> Hi all,
> facing the difficulties in making my plugins compatible with Trac 1.0
> I'm thinking whether to drop support for Trac 0.11 at least.

Don't hesitate to share the difficulties you had when "upgrading" your
plugins. We can always improve the documentation.

> Is there anywhere a usage statistics figure telling how much each Trac
> version is used?

You could gather some version usage info from the TracUsers page on
t.e.o (http://trac.edgewall.org/wiki/TracUsers).

> If not, may we suggest a poll?

No idea if such a poll would be effective... I'd say it won't help much.
On our side, it's been clear that Trac 0.11 is no longer maintained
since 2 years (last changeset on /branches/0.11-stable was committed the
2012-10-16), so I suppose by now the message should have passed.

Therefore better *drop* the support for 0.11, and see what happens ;-)

If you haven't already, you can always branch later a 0.11 version at
the point you started the conversion, if that proves to be necessary.

-- Christian

[Steffen Hoffmann]

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

On 03.10.2012 17:37, Roberto Longobardi wrote:
> Hi all,
> facing the difficulties in making my plugins compatible with Trac 1.0
> I'm thinking whether to drop support for Trac 0.11 at least.
>
> Is there anywhere a usage statistics figure telling how much each Trac
> version is used?

Questions like these come up from time to time.

There continue to be no good numbers available, and I'm even clueless
what should count in there.

Downloads? We don't track them yet, on t-h.o at least. Not aware of
someone actually doing it.
Installs? One plugin package could be inherited and used in dozens of
Trac environments.
Users? There are just sessions, so in absence of a decent concept for
users this can be blurred too.
Polls? Do it, but many admins, not to speak of users won't care to vote
at all.

Best to take a look at http://trac.edgewall.org/wiki/TracUsers
and you'll see, that 0.11.x has still a very solid user base.

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

iEYEARECAAYFAlBsY98ACgkQ31DJeiZFuHeCZgCglV8L8cdA+kX7Xx0VblKZUq/C
TfsAn09PBQ66chIa5/cZiBjmBzvOHIxS
=QHs8
-----END PGP SIGNATURE-----

[Christopher Nelson]

> facing the difficulties in making my plugins compatible with Trac 1.0 I'm
> thinking whether to drop support for Trac 0.11 at least.
>
> Is there anywhere a usage statistics figure telling how much each Trac
> version is used?
>
> If not, may we suggest a poll?

FWIW, I'm stuck in 0.11.6. Hoping to jump to 1.0 in the next few months.

[Christopher Nelson]

>> Is there anywhere a usage statistics figure telling how much each Trac
>> version is used?

> ...

> Therefore better *drop* the support for 0.11, and see what happens ;-)
>
> If you haven't already, you can always branch later a 0.11 version at
> the point you started the conversion, if that proves to be necessary.

> ...

I hope I don't have to create version-specific branches of my plugins
because I haven't been able to figure out how to create branches at
t-h.o!

[Peter Suter]

On 03.10.2012 18:05, Christian Boos wrote:
> Trac 0.11 is no longer maintained
> since 2 years (last changeset on /branches/0.11-stable was committed the
> 2012-10-16)

On 2010-10-16 actually. :)

-- Peter

[Roberto Longobardi]

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.

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.

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

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.

(BTW, Genshi strict need for unicode strings was soon patched by one of my users :D)

Anyone has developed such a generic code?

Ciao,

Roberto

[1] This code, from line 87, used for example as this, from line 474.

2012/10/3 Peter Suter <pets...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac...@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.

[Steffen Hoffmann]

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

[Dirk Stöcker]

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)

[Roberto Longobardi]

>>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 <tr...@dstoecker.de>

[Sergii Galashyn]

Just a personal note on your question.

I am using like 10 different Trac instances for my and client's projects and most of them are private (usually auth-protected). We have different versions, mostly 0.11 and 0.12 -- it doesn't make much sense to care about upgrade when everything works just fine since installation.

And I suspect this is pretty usual way.

What I am trying to say is that all of the methods to find out how many instances are there wont include any of these. Well, except sending anonynous stats from the Trac to central server, but I'm not sure this is good idea.

I don't mind taking part in some poll, though I'm not sure I'll be able to recall all the details easily, for example versions of each Trac I'm using.

Thanks,
-sg

[Brettschneider Falk]

Sergii Galashyn wrote:
> What I am trying to say is that all of the methods to find out how many
> instances are there wont include any of these.

I think it's not interesting for the version statistics to know the absolute count of but instead the number of sites using it. That would be quite equal to the poll counter, so I support a poll. Although there will be some bias since active people tend to use newer versions, and most poll participants will be of the active crowd.
P.S.: This topic is related to bullet 3 of http://trac-hacks.org/wiki/SiteUpgradeProposal#WishList.

CU, F@lk

----
Falk Brettschneider
R&D Software
Baumer Optronic GmbH
www.baumer.com




Gesch?ftsf?hrer: Marcel Seeber * Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE 189714583

[Roberto Longobardi]

>>Well, except sending anonynous stats from the Trac to central server, but I'm not sure this is good idea. 

I agree with this, anyway we may think about, as a final step of a Trac installation, being directed to an official Trac web site page where one can "register" its use of a particular Trac version.

Much the same as may software products or devices do.

You may object that many people would just ignore it, but some may not :D

The registration page should be very quick to fill, possibily even pre-filling some parameters based on the user's network domain (with reverse DNS lookup), location, timezone and locale, installed plugins (even if this would be empty if only triggered at installation time), and so on.

Of course, the user may cancel at any time, thus preserving his/her privacy.

Alternatively, a permanent function like this may be available in the Admin panel, to send registration info at any convenient time.

Just my 2€c :D

Of course, a poll is another solution, though I share Falk's concerns about the active crowd bias.

Roberto

2012/10/5 Brettschneider Falk <fbretts...@baumer.com>

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.

To post to this group, send email to trac...@googlegroups.com.

To unsubscribe from this group, send email to trac-dev+u...@googlegroups.com.

[Brettschneider Falk]

Brettschneider Falk wrote:
> ... absolute count of but instead the number of sites using it...
...absolute count of *instances* but instead the number of sites using it...

[Dirk Stöcker]

On Fri, 5 Oct 2012, Brettschneider Falk wrote:

> Sergii Galashyn wrote:
>> What I am trying to say is that all of the methods to find out how many
>> instances are there wont include any of these.
>
> I think it's not interesting for the version statistics to know the absolute count of but instead the number of sites using it. That would be quite equal to the poll counter, so I support a poll. Although there will be some bias since active people tend to use newer versions, and most poll participants will be of the active crowd.
> P.S.: This topic is related to bullet 3 of http://trac-hacks.org/wiki/SiteUpgradeProposal#WishList.

Search using Google: ---inurl:TracInterfaceCustomization intext:"Powered by Trac 0.9"---

0.9: 45
0.10: 1890
0.11: 15500
0.12: 399
0.13: 5
1.0: 0

Note: These stats aren't 100% secure, but are a pretty good indication,
what is around. And much better than any poll can be.

[Brettschneider Falk]

Dirk Stöcker wrote:
> Search using Google: ---inurl:TracInterfaceCustomization intext:"Powered
> by Trac 0.9"---
>
> 0.9: 45
> 0.10: 1890
> 0.11: 15500
> 0.12: 399
> 0.13: 5
> 1.0: 0

But your internet search does not contain intranets. How would you predict their versions?

CU, F@lk

----
Falk Brettschneider
R&D Software
Baumer Optronic GmbH
www.baumer.com

Geschäftsführer: Marcel Seeber · Dr. Oliver Vietze

[Dirk Stöcker]

On Fri, 5 Oct 2012, Brettschneider Falk wrote:

>> 0.9: 45
>> 0.10: 1890
>> 0.11: 15500
>> 0.12: 399
>> 0.13: 5
>> 1.0: 0
>
> But your internet search does not contain intranets. How would you predict their versions?

Reading the last line of the posting (the one you stripped above) would
have helped:

[Franz]

Thanks Dirk for your Internet search - it's interesting. But there might also be Trac-sites, which omit the "Powered by" (for example the development site of CKEditor [1]). But I agree it's a good indication ...

Just for the reputation and counting of Trac 1.0 - we use it already in production.

Cu Franz


[1] http://dev.ckeditor.com/about

[Dirk Stöcker]

On Thu, 11 Oct 2012, Franz wrote:

> Thanks Dirk for your Internet search - it's interesting. But there might
> also be Trac-sites, which omit the "Powered by" (for example the
> development site of CKEditor [1]). But I agree it's a good indication
> ...

Yes. Looking at the hand-made TracUsers page, which I helped updating,
that are probably below 5%, but you are right.

> Just for the reputation and counting of Trac 1.0 - we use it already in production.

Give Google some time. All my instances are also 1.0 and not counted yet.
You get some higher numbers when you don't restrict the search for an
individual page, but that counts one installation multiple times.