> > Yes, I do know. I think it's a terrible idea to do development in a tag > because ... > > > I am concerned that we are goingbro introduce a stumbling block to new devs > > coming in by creating a non standard use of svn. > > ... oh, you just made my point for me :) > > -- > Michael C. Harris, School of CS&IT, RMIT > Universityhttp://twofishcreative.com/michael/blog > IRC: michaeltwofish #habari
Entirely agreed. Which is also why i made my earlier points about the purpose of trunk vs branches. Main dev is in trunk. This is the standard use of svn. If you want to make a version of a plugin for an older version, branch it and do it. The trunk should be working towards working with the current version of habari. if there needs to be work done on a prior version, branch it. that means trunk is always latest. > I express no opinion, but tags can be created from anywhere, and version > branches are common. A branch in a plugin that is compatible with a stable > version of Habari, and from which tags are made is reasonable for bug fixes > etc. Agreed. You can easily create a tag from a branch. <storyteller> Indeed you would if you wanted to release a new version of an plugin for an old version of habari. ie lets say we're up to 0.8, and you found a security bug in your plugin, that you have previously released version 0.1 for 0.6 and 0.2 for 0.7 and 0.6. For updating releases to fix code bugs, lets assume for the moment you use release version numbers (ie 0.0.x) so the plugin would be currently laid out thus (you're a very clean person, and you clean up your branche): plugin \trunk <- main dev of your plugin for 0.8 \branches \tags \0.6-0.1 \0.6-0.2 \0.7-0.2 Now you start work on your bug. You need to make two new releases. So you create thus: \trunk <- main dev for 0.8 \branches \0.6-0.2.1 \0.7-0.2.1 \tags \0.6-0.1 \0.6-0.2 \0.7-0.2 You might have branched from the last tag, or the trunk. whatever you felt was easier. Then you fix your buggy code, and you want to release it to the world. Now we have: \trunk <- main dev for 0.8 \branches \tags \0.6-0.1 \0.6-0.2 \0.6-0.2.1 \0.7-0.2 \0.7-0.2.1 You are not ready to release your plugin for 0.8, because you want it to have laser beams, and they are not ready on the internets yet. NOW! What happens is I come along, and i have 0.7 of habari, so i get the highest version in the 0.7 set that i can. Oh look! it's 0.7-0.2.1. I don't know what that scary trunk is, so i leave it alone. Or, i have 0.6, so i get the tag of 0.6-0.2.1. Alternately, i am super-dev, and i only ever run trunk of habari. In this case, i can check out from trunk, and be a leet hacker coder. One more case: Let's say, 0.8 got released yesterday, and i want this plugin. I have a couple of choices. a) I can wait for the author to release a 0.8 tag. This is what will show up whenever on plugin sites anyway. b) i can be adventurous, and see if a previous tag works. From here, two options b) i) It works. Yay i tell a habari dev, and they retag as a release after a bit of testing b ii) It doesn't work. Either i try to fix, or see options a) or c). c) I can be adventurous, and see if trunk works. From here, same two options as b). </storyteller> RIGHT. so i've now laid out the use cases where i see them fit. I think that this layout is the most consistent with the original designs of standard svn layouts (to address michael's concern's about accessibility), and i also think this i the most maintainable (addressing others concerns). I also think that this is the most detailed proposition so far. I would like to see the other options laid out with these use cases, as i have no particular affinity with this solution, i just don't think the others work as well. Cheers! --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
