Some time ago I've updated the ApiChanges page for 1.1.1, proposing a
few changes that I think would be good to undertake early in the 1.1.x
development cycle.
Among these, I suggest that we now only target Python 2.6 and 2.7,
and I highlight there a few possible benefits of dropping 2.5 support.
Another "benefit" would be to get the syntax closer to Python 3 (3.3 and
beyond, see #10083).
So for those who have not yet reviewed the proposed changes, this is the
occasion to do so and give me some feedback about it ;-)
Christian Boos wrote:
> So for those who have not yet reviewed the proposed changes, this is the
> occasion to do so and give me some feedback about it ;-)
All good for me. I'm not sure it's worth switching from the implements()
function to a class decorator, but it *would* cut down on the magic.
> On 03.10.2012 12:51, Christian Boos wrote:
>> So for those who have not yet reviewed the proposed changes, this is the
>> occasion to do so and give me some feedback about it ;-)
> Sounds good to me. Are there already tickets associated with these, or
> should new ones be created when a particular point gets tackled?
I just created one for Babel 1.0 support, because there was an actual
issue (#10882).
And yes, for the other items, new tickets can be created if there's
something to discuss or if there are patches to review.
> Some time ago I've updated the ApiChanges page for 1.1.1, proposing a
> few changes that I think would be good to undertake early in the 1.1.x
> development cycle.
> Among these, I suggest that we now only target Python 2.6 and 2.7,
> and I highlight there a few possible benefits of dropping 2.5 support.
> Another "benefit" would be to get the syntax closer to Python 3 (3.3 and
> beyond, see #10083).
> So for those who have not yet reviewed the proposed changes, this is the
> occasion to do so and give me some feedback about it ;-)
Date type custom fields would be nice.
I worry how I'm going to support multiple version of Trac in my
plugins since I can't figure out how to branch in svn at T-H.o, let
alone make it talk nice with my local git repositories.
This is about #1942, finally implemented with
type = time
format = date
since [11333] in `trunk` for 1.1, if you want to test it. I use this
code and predecessors in production for years now - indispensable for me.
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
I would vote against this:
*
*
*>>The @with_transaction(env) / @env.with_transaction() decorators
introduced in 0.12 which have been deprecated in Trac 1.0 have been removed
as well.*
I understand that the new syntax is more functional, but removing this one
would force plugin maintainers to fork their code in order to keep support
for 0.12 and 1.1.1 at the same time.
Roberto
2012/10/3 Christopher Nelson <chris.nelson.1...@gmail.com>
> > On 03.10.2012 20:19, Christopher Nelson wrote:
> >> how to branch in svn
> > Just copy you plugin code to a named directory below
> > <your-plugin>/branches/your_plugin-<major>.<minor>
> > In contrast to Mercurial SVN has no distinct concept of branches, and I
> > guess that's the same story for Git.
> I have no access to SVN. I use git locally and git-svn to copy
> to/from T-H.o.
> My problem is, if I create a branch with:
> git checkout -b Trac-0.11 master
> what do I then add to
> git svn ...
> to push that branch to T-H.o?
> Chris
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to trac-dev@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.
