Opened 6 years ago

Closed 10 months ago

# [PATCH] for Trac 1.0 compatibility

Reported by: Owned by: Mario Ryan J Ollos low TagsPlugin normal wiki formatter Ryan J Ollos 1.0

### Description

Hi,

I just updated my Trac env. to 0.13, enclosed you will find some patches for 0.13 compatibility.

Trac 0.13 rev 10391 TagsPlugin rev 9419

have fun

Mario

### comment:1 Changed 6 years ago by Steffen Hoffmann

Cc: Ryan J Ollos added; anonymous removed wiki formatter added 0.11 → 0.12

Thanks for the contribution.

I use Trac 0.13dev without problems and noticeable functional degradation. So would you kindly provide some insight in what the changes to obviously new syntax of formatters do for TagsPlugin? No question, this should be the way to go for the trunk development branch towards upcoming Trac releases, but is it in any way already required for next release? I don't feel so.

Sidenote: While I push it up to Trac Release 0.12, this should really be 0.13 .

### comment:2 follow-up:  13 Changed 5 years ago by Steffen Hoffmann

Priority: normal → low

Missing response seems to confirm, that this would just enhance the code.

But it comes at the cost of loosing Trac 0.11 backwards compatibility, so this shouldn't get into trunk before we've branched to a dedicated 0.13 development line. This is even less pressing, as Trac is still 0.13dev by now.

### comment:3 Changed 4 years ago by Steffen Hoffmann

Summary: [PATCH] for Trac 0.13 compatibility → [PATCH] for Trac 1.0 compatibility

### comment:4 follow-ups:  5  6  7  16 Changed 3 years ago by henning.sprang@…

Hi, I stumbled across this after trying to install the 0.6 plugin onto my 1.0.1 install and failed.

As 0.X versions are not what is recommended to people they should run, I believe supporting the current stable version should be a higher priority than "low" and also a higher severity.

In fact, for me it just keeps me from starting to use it, but all people that would want to upgrade to 1.x but using the tag plugin, are hindered.

If there's any help needed to make this happen, I happily volunteer to do anything that's helpful!

Cheers

Last edited 10 months ago by Ryan J Ollos (previous) (diff)

### comment:5 in reply to:  4 Changed 3 years ago by Ryan J Ollos

I stumbled across this after trying to install the 0.6 plugin onto my 1.0.1 install and failed.

Please install from the trunk (0.7dev), you'll find that the issue is resolved.

We just need to finally release 0.7, however imperfect it might be, because having an indefinite release date for 0.7 is causing more trouble than we encounter by just getting it out there.

Last edited 3 years ago by Ryan J Ollos (previous) (diff)

### comment:6 in reply to:  4 Changed 3 years ago by Steffen Hoffmann

If there's any help needed to make this happen, I happily volunteer to do anything that's helpful!

As Ryan already pointed out 0.7dev in trunk is the release candidate. If you test it and provide feedback here, this would be both welcomed and most helpful at the moment.

Last October/November we did significant API and db backend changes. So a release is not as much overdue as it has been before. However I agree, that I should give the release top priority now and shift development focus to the next release cycle. Thanks for making that clear.

### comment:7 in reply to:  4 ; follow-up:  8 Changed 3 years ago by Steffen Hoffmann

Hi, I stumbled across this after trying to install the 0.6 plugin onto my 1.0.1 install and failed.

Not due to missing state-of-the formatter API support, that is suggested here.

As 0.X versions are not what is recommended to people they should run, I believe supportung the current stable version should be a higjer priority athan "low" and also a higher severity.

Sorry, but this is almost rubbish.

First, Trac itself has not been less mature at 0.12 than now at 1.0, so it is not much different with plugin version numbers.

Second, we do not need to support all current APIs to support current stable Trac. We will likely need it for some later Trac version, but that is a different subject, right?

Third, did you look at the enclosed patch? Even the reporter failed to make the difference clear, performance-wise. I. e. recent db backend API support will always get higher priority than formatter API, as long as the latter doesn't break something (more) fatally, of course.

In fact, for me it just keeps me from starting to use it, but all people that would want to upgrade to 1.x but using the tag plugin, are hindered.

Again, your assertion is not true, not for this ticket.

Ultimately, would you be so kind as to redirect feedback regarding installation issues to the mailing list, or the correct ticket. That would rather be #9521. And that one already has the attributes you demand here.

### comment:8 in reply to:  7 ; follow-up:  9 Changed 3 years ago by anonymous

Sorry, but this is almost rubbish.

That's an interesting change in the tone of the conversation after your first pretty positive reply.

### comment:9 in reply to:  8 Changed 3 years ago by Steffen Hoffmann

Sorry, but this is almost rubbish.

That's an interesting change in the tone of the conversation after your first pretty positive reply.

Yes, indeed. The first is a reaction on a fellow developers hint. The second is regarding vague assertions, that effectively have been hijacking the wrong ticket anyway, as I pointed out clearly in the end. To be honest, its hard to stay so calm at times.

### comment:10 follow-up:  11 Changed 3 years ago by anonymous

Highjackin is an intentional doing, writing an eventually not 100% perfect comment on a ticket that, after deeper studying, might be on another detail, is an accident. Basically, the ticket main text and description just sounds like it is about the 1.0 incompatibility problem. Right I didn't study the patch fully, and I might simple not have understood your comment.

Still, there's no reason to take such a thing as a personal insult and react on it by insulting back on somebody who never intended to insult you.

Furthermore, the partly wrong feedback was primarily based on the indisputable fact that the plugin is outdated, and that's still true. I never talked about what's the difference between 0.12 and 1.0 - it's just a fact that 1.0 is the recommended version to be installed, and the plugin isn't compatible with tat version.

So very first you could have avoided the problems if you'd properly maintain your software and let it not linger around in outdated ways.

In general, If you can't deal with such things, maybe publishing software and running a public ticket system for it just isn't your cup of tea. But that's not my fault. Calm down, and learn to be nicer, or just stop doing things you hate.

### comment:11 in reply to:  10 Changed 3 years ago by Ryan J Ollos

Furthermore, the partly wrong feedback was primarily based on the indisputable fact that the plugin is outdated, and that's still true. I never talked about what's the difference between 0.12 and 1.0 - it's just a fact that 1.0 is the recommended version to be installed, and the plugin isn't compatible with tat version.

Repeating comment:5: the plugin is fully compatible with Trac 1.0. You must install from the tagsplugin/trunk.

### comment:12 follow-up:  14 Changed 3 years ago by anonymous

Which is nowhere documented apart from here, after the things that happened.

Apart from that, using trunk is not what should matter to end users, therefore, implicitly my latest writing was about the *latest released version* of the plugin as installed by the instructions, which doesn't work with the *latest released and recommended for install* version of TRAC.

You've been right with your first comment, the only solution is to release a compatible version.

Insulting users for being what you think is stupid just brings us that far, it kills the motivation to help that has also been offered in the first, criticized comment.

### comment:13 in reply to:  2 Changed 3 years ago by Ryan J Ollos

Trac Release: 0.12 → 1.0

Missing response seems to confirm, that this would just enhance the code.

It appears to me as well that this is nothing more than a refactoring and not strictly needed for Trac 1.0. Further, part of the patch is not needed, and it appears to have been copied directly from the web_context documentation. That is, the following code does nothing:

ctx.href is req.href
ctx.perm is req.perm


To have any meaning, it would need to be proceeded by an assert at least, and I don't believe that is necessary.

To concisely summarize this ticket for future reference, the aim could be to replace Context.from_request with web_context and Context with RenderingContext, once support for Trac 0.12 is dropped on the development line (next major release after 0.7?).

Btw, there is no documentation in Trac about when web_context and RenderingContext were added ([trac 10328#file39]), but they are not on the 0.12-stable branch, and I think you already had a clear undertstanding that they were added in 0.13dev. Still, I get confused, so I'm making an action item for myself to add to the documentation :since 1.0: (trac:#11490).

### comment:14 in reply to:  12 Changed 3 years ago by Steffen Hoffmann

@rjollos
Thanks for finally commenting on the ticket subject as I've been hoping someone would do for so long. This is the best that could happen.

@ our anonymous participant
I accept your apologies for initially taking this enhancement request as a 1.0 incompatibility problem (= bug).

You shouldn't have commented more after comment:7, because I asked you to use the mailing-list, if and as long as you are not sure about your issue, i.e. to what reason and to which ticket it could belong respectively. We didn't see any details on your issue yet, did we? Even if I already deduced the likely reason in an honest attempt to help you, I saw no error message, no trace-back, etc. yet.

Which is nowhere documented apart from here, after the things that happened.

It is, but in #9521, as it should. And in this ticket, because I've already directed you there after looking for the real reason of your complaint. It is not yet in the plugin's changelog and not within other, more prominently advertised issues on plugin's (wiki) front page, sure, sorry for that. It will be fixed by the next release, or earlier.

Btw, next release's commit message has been prepared nearly a year back from now in my patch queue and it is still waiting there, because the focus on pressing performance issues (#4503) took far too much of my total spare time for Trac development. Please look at all the things that happened, documented in the commit history while you scroll down to [12069], where the thing happened, that likely is the most important change for your unpleasant observation.

Apart from that, using trunk is not what should matter to end users, therefore, implicitly my latest writing was about the *latest released version* of the plugin

No need to emphasis here, it came through clearly already.

You've been right with your first comment, the only solution is to release a compatible version.

I see. But at the same time you're directly accusing me of insulting users (comments 10 + 12). It is not exactly wise to do that in the overall context, is it? Anyway, neither was an insult intentional, nor did I expect such interpretation of my - admittedly firm - words in comment:7 before.

I urge you to accept my apologies because you obviously felt insulted after all, maybe due to comment:9, where I already hinted on my own uneasy feelings about the direction that this conversation had run into. Or due to the fact, that I'm no native English speaker. So I did not weight out all meanings of 'hijacking' but wrote it down as a typical phrase for using a wrong thread.

Insulting users for being what you think is

Stop. You're still "anonymous". Disclose your real identity before going for such length as to suggest what I may think, please. More such words draw even more from your positive intention to help.

stupid just brings us that far, it kills the motivation to help that has also been offered in the first, criticized comment.

Criticized, yes, of course. I gave three reasons why, that you did not deny at all. Stupid, No. At least I fail to see the words of mine, that suggest that. But my honest apologies apply here too.

Here we are. You may still feel insulted. Me too, because you suggested that I may treat users badly and may not be fit for the 100% spare time 'job' of maintaining this Trac hack that I may even hat to do. Because I'm not careless, ignorant, tough, etc. by no means.

So let's shut this down here and now, please.

### comment:15 Changed 3 years ago by Steffen Hoffmann

Did I mention, that some IT guys regularly laugh at me for being so stupid as to do as much quality and quantity of development and user support as they do, but for free?

### comment:16 in reply to:  4 Changed 3 years ago by Steffen Hoffmann

Hi, I stumbled across this after trying to install the 0.6 plugin onto my 1.0.1 install and failed.

For what its worth I've slightly improved the situation this evening by

a) linking to trunk as tags-0.7rc on the TagsPlugin wiki page (version 74) b) announced a definitive release date in our news box on the same page

### comment:17 Changed 2 years ago by Robert W. Baumgartner

I've attached a patch to get the TagsPlugin working with Trac v1.1.4 to #12137; please see my comment to that ticket.

### comment:18 Changed 18 months ago by Ryan J Ollos

Owner: changed from Michael Renzmann to Steffen Hoffmann new → assigned

### comment:19 Changed 18 months ago by Ryan J Ollos

In 14949:

0.9dev: Remove fallback for Trac<0.11.3

Refs #8345.

### comment:20 Changed 18 months ago by Ryan J Ollos

In 14950:

0.9dev: Remove compatibility code for Trac < 1.0

Refs #8345.

### comment:21 Changed 18 months ago by Ryan J Ollos

In 14951:

0.9dev: Remove compatibility functions for translation

Refs #8345.

### comment:22 Changed 18 months ago by Ryan J Ollos

In 14952:

0.9dev: Remove duplicated import.

Refs #8345.

### comment:23 Changed 10 months ago by Ryan J Ollos

In 15564:

0.9dev: Replace use of deprecated Context.from_request

Refs #8345.

### comment:24 Changed 10 months ago by Ryan J Ollos

Owner: changed from Steffen Hoffmann to Ryan J Ollos assigned → accepted

### comment:25 Changed 10 months ago by Ryan J Ollos

Resolution: → fixed accepted → closed

### comment:26 Changed 10 months ago by Ryan J Ollos

I'll create the 0.9 release and upload to pypi:TracTags in a short while, if no additional issues are raised.

Last edited 10 months ago by Ryan J Ollos (previous) (diff)

### Modify Ticket

Change Properties