Opened 10 years ago
Closed 7 years ago
#12373 closed task (wontfix)
Development roadmap
| Reported by: | Cinc-th | Owned by: | falkb |
|---|---|---|---|
| Priority: | normal | Component: | SimpleMultiProjectPlugin |
| Severity: | normal | Keywords: | |
| Cc: | Trac Release: | 0.12 |
Description
Hi falkb,
I'd like to discuss a little bit the future development roadmap to get an idea what you have in mind for the plugin.
I think about doing the following next:
- Implement #12031, allow several projects to have the same milestone (I need that one, too)
- Remove the component panel in the
Manage Projectssection - Refactor model.py which is rather huge by now
We should think about dropping Trac 0.11 support and only go for 0.12 and 1.x to make the database code cleaner.
- The current tree should be tagged so people have a stable plugin to use while doing work in trunk.
For the long term it's maybe worth thinking about moving to BSD license because Trac and most of the plugins are following this license and so it would help to share code. This will happen more or less automatically when new code is added only as BSD.
Attachments (0)
Change History (11)
comment:1 follow-up: 2 Changed 10 years ago by
comment:2 follow-up: 3 Changed 10 years ago by
Replying to falkb:
Though I'm driven by what I need for Trac here at work, and it's actually quite sufficiently running well, so there's not much will for taking time for it at present... :)
Same here.
I think about doing the following next:
- Implement #12031, allow several projects to have the same milestone (I need that one, too)
Sounds good, although we should also provide it for the field "version" as well then, because a milestone usually releases a certain version. (BTW: Here, we actually mainly heading for versions as target of a plan for software, and a milestone is just a special event in the plan on a higher level of planning a project (ISO quality management stages).)
If it works for milestones an implementation for versions is probably easy to do.
- Remove the component panel in the
Manage ProjectssectionI have another (just local) plugin that also adds a new column to the table on the components Admin page. I noticed trouble if more than one plugin wants to add a new column there, and so I decided to keep it on an own Admin page. If you can find an approach which works not only for one plugin, it's fine with me.
Is the other plugin public so I may have a look into it? At first sight I'd say the new SMP feature doesn't do anything hackish. Just some Genshi filtering stuff.
We should think about dropping Trac 0.11 support and only go for 0.12 and 1.x to make the database code cleaner.
Yes, I have not 0.11 for testing, either. That's why no chance for me to ensure 0.11 support anyway.
Ok, so I drop that one. I have no means to test either. Will make a copy to a 0.11 branch before starting to break stuff for that version (which will for sure happen...).
- The current tree should be tagged so people have a stable plugin to use while doing work in trunk.
Actually, my activities have been in a way that the trunk is always usable and stable. So there was no need for branches. Unfinished stuff was always not committed because that doesn't make much sense for me, the development branch is my local machine here... ;) I'm also not sure about the version numbering, so I never chose 1.0.
Only reason is to be able to tell people to use the latest tag if for some reason the trunk doesn't work for them. I don't want to educate someone in a ticket comment how to checkout a specific working subversion revision ;-).
For the long term it's maybe worth thinking about moving to BSD license because Trac and most of the plugins are following this license and so it would help to share code. This will happen more or less automatically when new code is added only as BSD.
I don't much care about all those Open Source licenses. Never heard about problems with certain ones... I think I reused the license that was used by crossroad (the former maintainer).
Ok. Will continue to submit features as BSD and we'll see if we end up as BSD in the end.
comment:3 follow-up: 4 Changed 10 years ago by
Replying to anonymous:
Replying to falkb:
- Remove the component panel in the
Manage ProjectssectionI have another (just local) plugin that also adds a new column to the table on the components Admin page. I noticed trouble if more than one plugin wants to add a new column there, and so I decided to keep it on an own Admin page. If you can find an approach which works not only for one plugin, it's fine with me.
Is the other plugin public so I may have a look into it? At first sight I'd say the new SMP feature doesn't do anything hackish. Just some Genshi filtering stuff.
I checked again, it's not local anymore. My colleague uploaded it already as ComponentHierarchyPlugin. It also adds a column where things get mixed up then. I think that was the reason to keep SMPP with its own component page. The blank row seems to be a different problem what I first need to find out here... sorry for the confusion.
We should think about dropping Trac 0.11 support and only go for 0.12 and 1.x to make the database code cleaner.
Yes, I have not 0.11 for testing, either. That's why no chance for me to ensure 0.11 support anyway.
Ok, so I drop that one. I have no means to test either. Will make a copy to a 0.11 branch before starting to break stuff for that version (which will for sure happen...).
I think I have dropped 0.11 support a while ago, already (it actually never fully have worked and there was a ticket for it)
- The current tree should be tagged so people have a stable plugin to use while doing work in trunk.
Actually, my activities have been in a way that the trunk is always usable and stable. So there was no need for branches. Unfinished stuff was always not committed because that doesn't make much sense for me, the development branch is my local machine here... ;) I'm also not sure about the version numbering, so I never chose 1.0.
Only reason is to be able to tell people to use the latest tag if for some reason the trunk doesn't work for them. I don't want to educate someone in a ticket comment how to checkout a specific working subversion revision ;-).
This convinces me!
comment:4 Changed 10 years ago by
Replying to falkb:
I checked again, it's not local anymore. My colleague uploaded it already as ComponentHierarchyPlugin. It also adds a column where things get mixed up then. I think that was the reason to keep SMPP with its own component page. The blank row seems to be a different problem what I first need to find out here... sorry for the confusion.
Aaaaah, I was wrong. Wait, it'll be uploaded soon...
comment:6 Changed 10 years ago by
comment:8 follow-up: 9 Changed 9 years ago by
Tagged the current version as 0.0.4.
I think the next version should be 0.5.0. It's time to reflect the feature set in the versioning ;-).
comment:9 Changed 9 years ago by
Replying to Cinc-th:
Tagged the current version as 0.0.4.
I think the next version should be 0.5.0. It's time to reflect the feature set in the versioning ;-).
Currently I don't have the time to look at work in progress but I'm very curious how that 0.5.0 snapshot will look like. :-) I'm going to try it as soon as you tagged it (and maybe put to the stable branch?).
comment:10 Changed 9 years ago by
There are currently some minor regressions in the trunk wrt to saving settings and stuff. I'm currently working on that. Aside from that all features are still in place afaics.
For the future I'd like to use Tracs user management for access control to projects by defining groups and membership using the user admin panel. That will probably need some rethinking of how stuff is done.
comment:11 Changed 7 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
topic burried after 2 years now. No activities anymore.
Hi Cinc-th,
Replying to Cinc-th:
That's a good idea. Well, I'm mainly interested in
Though I'm driven by what I need for Trac here at work, and it's actually quite sufficiently running well, so there's not much will for taking time for it at present... :)
Sounds good, although we should also provide it for the field "version" as well then, because a milestone usually releases a certain version. (BTW: Here, we actually mainly heading for versions as target of a plan for software, and a milestone is just a special event in the plan on a higher level of planning a project (ISO quality management stages).)
I have another (just local) plugin that also adds a new column to the table on the components Admin page. I noticed trouble if more than one plugin wants to add a new column there, and so I decided to keep it on an own Admin page. If you can find an approach which works not only for one plugin, it's fine with me.
Not my focus but why not, if it keeps simplicity and doesn't break things.
Yes, I have not 0.11 for testing, either. That's why no chance for me to ensure 0.11 support anyway.
Actually, my activities have been in a way that the trunk is always usable and stable. So there was no need for branches. Unfinished stuff was always not committed because that doesn't make much sense for me, the development branch is my local machine here... ;) I'm also not sure about the version numbering, so I never chose 1.0.
I don't much care about all those Open Source licenses. Never heard about problems with certain ones... I think I reused the license that was used by crossroad (the former maintainer).