#8345 closed enhancement (fixed)
[PATCH] for Trac 1.0 compatibility
Reported by: | Mario | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | low | Component: | TagsPlugin |
Severity: | normal | Keywords: | wiki formatter |
Cc: | Ryan J Ollos | Trac Release: | 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
Attachments (1)
Change History (27)
Changed 14 years ago by
Attachment: | TagsPlugin.patch added |
---|
comment:1 Changed 13 years ago by
Cc: | Ryan J Ollos added; anonymous removed |
---|---|
Keywords: | wiki formatter added |
Trac Release: | 0.11 → 0.12 |
comment:2 follow-up: 13 Changed 13 years ago by
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 12 years ago by
Summary: | [PATCH] for Trac 0.13 compatibility → [PATCH] for Trac 1.0 compatibility |
---|
comment:4 follow-ups: 5 6 7 16 Changed 11 years ago by
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
comment:5 Changed 11 years ago by
Replying to henning.sprang@…:
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.
comment:6 Changed 11 years ago by
Replying to henning.sprang@…:
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 follow-up: 8 Changed 11 years ago by
Replying to henning.sprang@…:
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 follow-up: 9 Changed 11 years ago by
Replying to hasienda:
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 Changed 11 years ago by
Replying to anonymous:
Replying to hasienda:
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 11 years ago by
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 Changed 11 years ago by
Replying to anonymous:
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 11 years ago by
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 Changed 11 years ago by
Trac Release: | 0.12 → 1.0 |
---|
Replying to hasienda:
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 Changed 11 years ago by
@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.
Replying to anonymous:
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 11 years ago by
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 Changed 11 years ago by
Replying to henning.sprang@…:
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
astags-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 10 years ago by
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 9 years ago by
Owner: | changed from Michael Renzmann to Steffen Hoffmann |
---|---|
Status: | new → assigned |
comment:24 Changed 9 years ago by
Owner: | changed from Steffen Hoffmann to Ryan J Ollos |
---|---|
Status: | assigned → accepted |
comment:25 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
comment:26 Changed 9 years ago by
I'll create the 0.9 release and upload to pypi:TracTags in a short while, if no additional issues are raised.
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 .