Hello, I am receiving the first patches to make tagadelic ready for 5. However, till today, I managed to keep tagadelic HEAD running very fine on 4.7. It got loads of nice features, improved code, and revised, more modular APIs. branch 4.7 tagadelic, and HEAD tagadelic are not compatible, so if I simply overwrite the 4.7 branch with tagadelic HEAD I will break a lot of people's sites. Hence I want to roll out a 4.7-2 soon, and then focus on 5.0. Questions: * Drupal does not allow me to create separate 4.7. Should i therefore use my own SVN to distribute that new version? * Does anyone (bryght, Civicspace, etc) have an infrastructure in lpace to distribute backported modules and features, which is could use instead of roling my own (see above). * What is the status of allowing 4.7.2 branches for modules? Should I rather wait for that? µ-Bèr -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
On Oct 3, 2006, at 6:54 AM, Bèr Kessels wrote:
* Does anyone (bryght, Civicspace, etc) have an infrastructure in lpace to distribute backported modules and features, which is could use instead of roling my own (see above).
We use our own SVN server to manage releases exclusively. We keep the source for all the modules in Drupal CVS. I would suggest Drupal CVS sandbox as a place to keep modules until the 5.0 branch opens up. Kieran
Bèr Kessels wrote:
Hello,
I am receiving the first patches to make tagadelic ready for 5. However, till today, I managed to keep tagadelic HEAD running very fine on 4.7. It got loads of nice features, improved code, and revised, more modular APIs. branch 4.7 tagadelic, and HEAD tagadelic are not compatible, so if I simply overwrite the 4.7 branch with tagadelic HEAD I will break a lot of people's sites.
the usual way to manage this in 4.7 and beyond is with hook_update() functions in your .install file. sometimes updates need some explaining, which i do in the commit message and in the readme file. you could also conceivably do a form_alter() on the update page in order to communicate stuff or gather settings.
On 10/3/06, Bèr Kessels <ber@webschuur.com> wrote:
Hello,
I am receiving the first patches to make tagadelic ready for 5. However, till today, I managed to keep tagadelic HEAD running very fine on 4.7. It got loads of nice features, improved code, and revised, more modular APIs. branch 4.7 tagadelic, and HEAD tagadelic are not compatible, so if I simply overwrite the 4.7 branch with tagadelic HEAD I will break a lot of people's sites.
Hence I want to roll out a 4.7-2 soon, and then focus on 5.0.
Questions: * Drupal does not allow me to create separate 4.7. Should i therefore use my own SVN to distribute that new version?
I haven't understood why you wouldn't just, essentially, release a new 4.7 version with more features. Are there schema changes?
* Does anyone (bryght, Civicspace, etc) have an infrastructure in lpace to distribute backported modules and features, which is could use instead of roling my own (see above).
As Kieran suggested, your sandbox would work. Ping Richard at support@bryght.com if anyone wants an account on our public SVN repo for anything Drupal related -- http://svn.bryght.com/dev/browser Backporting is an interesting issue. We'll likely be maintaining a couple of things in that repo in public -- e.g. jQuery for 4.7.
* What is the status of allowing 4.7.2 branches for modules? Should I rather wait for that?
/me waves at DWW -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Op dinsdag 3 oktober 2006 19:50, schreef Boris Mann:
I haven't understood why you wouldn't just, essentially, release a new 4.7 version with more features. Are there schema changes?
'Till today, there is no database stuff needed for tagadelic, so hook_update, nor any .install tricks will help. (its a tableless module) What I am afraid of, is my changed APIs. Anyone whom either calls tagadelic APIs in a block, his/her own modules, themes, php-pages or whatever home-made code, will be faced with a broken site if he/she runs a CVS up of the stable DRUPAL-4-7 branch, if I were to replace that version with the one from HEAD. I have been hit by this several times myself (most notable: I broke 40 sites last month because suddenly the 4.7 image module was changed completely, it took me a whole night of database-poking to get it streight again). So I strongly and firmly beleive that a once-released module should only get bugfixes and never, ever release completely overhauled code on that same tag/branch. A new version belongs on a new 'place'. -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
Bèr Kessels wrote:
I have been hit by this several times myself (most notable: I broke 40 sites last month because suddenly the 4.7 image module was changed completely, it took me a whole night of database-poking to get it streight again). So I strongly and firmly beleive that a once-released module should only get bugfixes and never, ever release completely overhauled code on that same tag/branch. A new version belongs on a new 'place'.
Thank dww, but we'll soonishly be getting the ability to actually do real releases and not this sort of moving tarball crud.
On Oct 3, 2006, at 10:50 AM, Boris Mann wrote:
* What is the status of allowing 4.7.2 branches for modules? Should I rather wait for that?
/me waves at DWW
right. it's coming along nicely. i'm trying to work out the final details and complications that the new system is facing b/c of the switch to 2-digit version numbers. see http://drupal.org/node/86863 if you care to help with any of that... my current (optimistic, probably unrealistic) estimate is that it'll all be done and installed on d.o in about 2 weeks. basic status report: - releases-as-nodes is almost entirely done (a few minor kinks for what we need) - integration w/ cvs is mostly done (a few minor kinks and complications, mainly from the 2 vs. 3 digit stuff) - the packaging script isn't started (but should be very easy, especially since i have the existing packaging script to work form) - integration with issue tracking is mostly working, but has some rough edges - the script to update d.o and convert all existing releases to nodes is almost entire done and tested (it'll just need a few modifications based on the final changes that come out b/c of the "minor kinks" above). - none of the fancy new features to take advantage of this stuff are started yet (e.g. email/RSS subscriptions to all releases from a project), but i hope to add at least a few of those within a week or so after the main system goes live. so, ideally, you'd just wait for this to go live before you either a) break the stable 4.7 version or b) fork yourself into another module distribution system. use your sandbox for now, and you'll be able to make any DRUPAL-4-7--N branches you want in a few weeks... thanks, -derek p.s. we could also open up the ability to make a DRUPAL-4-7--N branch right now, and you could commit your code there, even though there'd be no releases packaged up for it yet. that's another option to consider. i think we're pretty much decided on that naming convention (-- as the delimiter between the core API branch and the contrib module's major revision number), so there's no real harm in starting to allow those branches now (unless anyone plans to object to this convention with a better proposal).
On 10/3/06, Derek Wright <drupal@dwwright.net> wrote:
p.s. we could also open up the ability to make a DRUPAL-4-7--N branch right now, and you could commit your code there, even though there'd be no releases packaged up for it yet. that's another option to consider.
I think this is a good idea. Having people test this will perhaps point to any changes that are needed in the rest of the infrastructure.
i think we're pretty much decided on that naming convention (-- as the delimiter between the core API branch and the contrib module's major revision number), so there's no real harm in starting to allow those branches now (unless anyone plans to object to this convention with a better proposal).
No. We are dww slaves. Command us, bird master! -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 04 Oct 2006, at 00:11, Boris Mann wrote:
i think we're pretty much decided on that naming convention (-- as the delimiter between the core API branch and the contrib module's major revision number), so there's no real harm in starting to allow those branches now (unless anyone plans to object to this convention with a better proposal).
I'm OK with that, if things are set in stone. -- Dries Buytaert :: http://www.buytaert.net/
On Oct 3, 2006, at 10:56 PM, Dries Buytaert wrote:
On 10/3/06, Derek Wright <drupal@dwwright.net> wrote:
i think we're pretty much decided on that naming convention (-- as the delimiter between the core API branch and the contrib module's major revision number)
I'm OK with that, if things are set in stone.
well, that's the question... at the talk i gave at drupalcon (http:// drupal.org/node/86694), everyone hated using an underscore '_' for this. e.g.: "DRUPAL-4-7_1" as the 1st development branch compatible with 4.7.x, and "DRUPAL-4-7_1-0" as the 4.7.x-1.0 release tag there were a few alternatives proposed during the discussion for a different delimiter than '_', such as '-V-', '-R-', '-REV-', etc. at barcamp, when i had a chance to speak to dries about it, he suggested (and i like) just using '--'. so, here are the viable contenders for branch and tag names: 1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0" 2) "DRUPAL-4-7-V-1" and "DRUPAL-4-7-V-1-0" 3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0" 4) "DRUPAL-4-7-REV-1" and "DRUPAL-4-7-REV-1-0" 5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender) this is your last chance to object to #1 being what we use. if anyone strongly protests (with a better suggestion), please speak up now or forever hold your peace. i don't want any sniveling complaints about this in 3 weeks when it's all live and you have to start using it, since it'll be too late to change at that point. thanks, -derek p.s. aside from this detail about the delimiter, for a pretty thorough but concise summary of how the new release system will work, you should read the 1-page handout i passed out at the druaplcon talk: http://drupal.org/files/new_release.pdf again, speak now, or love every bit of it and forever shut-up about your complaints. ;) <span class="dww-anal"> p.p.s. it doesn't *really* matter, but if a module's version number is "4.7.x-1.0", the "4.7.x" part is clearly the API-compatibility version. the "0" is obviously the patch level. what should we call the "1"? is that the major revision or the minor revision? in my email quoted above, i called it "major", but does it make more sense to refer to this as the "minor" revision, and think of the API- compatibility stuff as the "major" revision? just curious what folks think, if anyone else actually cares about this. ;) </span>
On Oct 4, 2006, at 12:55 AM, <karoly@negyesi.net> <karoly@negyesi.net> wrote:
What is there to discuss then?
i know these are major changes that everyone who maintains something in contrib is going to have to live with. i'm just giving people a final chance to speak up in case there are any complaints that can be easily addressed now, instead of impossible to address in 1 week... originally, i was planning to use '_', but popular outcry stopped me from going down that (i'll admit) somewhat lame path. i'm just making sure there are no other crappy things people are going to hate once this all goes live...
just do it.
already working on my local site. ;) i'll be uploading patches shortly to http://drupal.org/node/83339 and http://drupal.org/node/ 84706 ... -derek
"Derek Wright" wrote:
1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0"
Tough choice between these two. This one (above) is visually quite useful, since it visually separates the main from the sub version. +1 for the above.
3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0"
Good. I like the patterned (and therefore machinable) separation. Each "space" between a hyphen contains a relevant and sequential part. In the option "1)" above, the "empty" space between consecutive hyphens is just slightly less machineable, in my view. (I am thinking about a script, say PHP or AppleScript, which breaks apart a file name string into constituent parts. This is sometimes helpful in automated file systems.) Even given this very minor logical difference, I still think I prefer the first pattern for ease of visual cues and for neutrality with respect to language ("revision" is an English word, even though quite common in software jargon and so this is probably not an issue worth any real political-cultural wrangling.) +.75 for the above.
5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender)
Whew! Thank the Gods. -- inkfree
On Oct 4, 2006, at 7:05 AM, inkfree press wrote:
(I am thinking about a script, say PHP or AppleScript, which breaks apart a file name string into constituent parts. This is sometimes helpful in automated file systems.)
here's the code already in cvs.module (well, in a patch[1]) for this, using the '--' delimiter: list($super_ver, $base_ver) = explode('--', $tag->tag); $super = explode('-', $super_ver, 5); $base = empty($base_ver) ? array() : explode('-', $base_ver); then, you've got 2 nice arrays to keep the 2 parts of your version string separate... ;) this also nicely handles the cases of regular branches that don't have the '--' (e.g. the default, stable DRUPAL-4-7 or DRUPAL-5 branch for a given contrib). keep in mind that the *file* names have nothing to do with this discussion. the subject says "CVS branch/tag conventions". the filenames will be like so: signup-5.x-0.1.tar.gz # official 5.x-0.1 release # 1st patch update release on stable DRUPAL-5 branch, from DRUPAL-5--0-1 tag signup-4.7.x-1.0.tar.gz # official 4.7.x-1.0 release # initial release off the DRUPAL-4-7--1 branch, from DRUPAL-4-7--1-0 tag signup-4.7.x-2.0-dev.tar.gz # nightly snapshot tarball from the DRUPAL-4-7--2 branch (no release tag) # (assuming there's no 4.7.x-2.0 release yet) once there's a 2.0 release, the snapshots will start being called "signup-4.7.x-2.1- dev.tar.gz, etc). ... # core releases would be unchanged: drupal-5.0-beta1.tar.gz drupal-5.0.tar.gz drupal-4.7.4.tar.gz ... make sense? -dww [1] http://drupal.org/node/84706#comment-142624 for the interested/ horrified reader.
Derek Wright wrote:
... keep in mind that the *file* names have nothing to do with this discussion. the subject says "CVS branch/tag conventions". the filenames will be like so:
signup-5.x-0.1.tar.gz # official 5.x-0.1 release # 1st patch update release on stable DRUPAL-5 branch, from DRUPAL-5--0-1 tag
signup-4.7.x-1.0.tar.gz # official 4.7.x-1.0 release # initial release off the DRUPAL-4-7--1 branch, from DRUPAL-4-7--1-0 tag
signup-4.7.x-2.0-dev.tar.gz # nightly snapshot tarball from the DRUPAL-4-7--2 branch (no release tag) # (assuming there's no 4.7.x-2.0 release yet) once there's a 2.0 release, the snapshots will start being called "signup-4.7.x-2.1-dev.tar.gz, etc). ...
make sense? Not quite. Why is there an x in the filename and not the release tag? Since there should always be a 1-1 mapping between a given (official) tar ball and a given tag, there shouldn't be any difference in the way the version numbers appear (modulo case, and in other situations, some special character mappings).
Gary
On Oct 4, 2006, at 1:32 PM, Gary Feldman wrote:
Why is there an x in the filename and not the release tag? Since there should always be a 1-1 mapping between a given (official) tar ball and a given tag, there shouldn't be any difference in the way the version numbers appear (modulo case, and in other situations, some special character mappings).
1) because everyone (myself included) thinks the '.x' part is helpful for end users to understand the compatibility: it helps drive home the point it works with any version of drupal core that matches the "4.7" part, not a specific 4.7.N release. so, that's what they'll see in the version box in the issue queue, what they (already) see in the taxonomy terms on drupal.org, in documentation, etc. since the end users have to see and deal with these files, the '.x' part in the filename should match everything else that's targeted for end users. 2) because we've never used a "-X" in the branch/tag names until now. by that standard, the "DRUPAL-4-7" branch should have been called "DRUPAL-4-7-X", but we've never done it that way, and i don't plan on changing that now. 3) because the tag already doesn't match the tarball's name (e.g. the tag says "DRUPAL-...", but the tarball is called "signup-..."). 4) because i assume (probably wrongly) that contrib maintainers have enough of a clue to be able to understand this stuff. ;) yes, we'll be working on making it more developer-friendly in the near future (e.g. you could go to some form wizard thingy on your project page and say "i want to make a new release, help me with the cvs crap", and it walks you through a few questions, figures out what version you plan to release, and dumps you out the cvs command-line you need to add the right tag, etc, etc). but, in the first instance, i don't think it's too much to ask to understand the basics of this system. furthermore, contrib maintainers that can't be bothered will just create a DRUPAL-4-7 or DRUPAL-5 branch, like they always have, and leave it at that. they'll get nightly snapshots from that branch. so, if they can't figure it out or don't care, they never tag any official releases and are stuck with the "4.7.x-0.0-dev" version of their module forever (which is equivalent to what they get now). -derek
Derek Wright wrote:
On Oct 4, 2006, at 1:32 PM, Gary Feldman wrote:
Why is there an x in the filename and not the release tag? Since there should always be a 1-1 mapping between a given (official) tar ball and a given tag, there shouldn't be any difference in the way the version numbers appear (modulo case, and in other situations, some special character mappings).
1) because everyone (myself included) thinks the '.x' part is helpful for end users to understand the compatibility: it helps
I understand how people who've been working on Drupal for a while might come to that conclusion, but I don't agree. The .x could just as easily be interpreted as eXperimental or eXtension (both conventions I've seen used before). It's the type of thing that will trip up many users, and not be of much help to others. The people who care about details will worry about it, and the people who don't care about details will just make the same assumptions with or without the .x. At a minimum, it's one more thing that they'll have to learn in order to join the club, and it doesn't get around the fact that they still need to worry about incompatibilities between modules.
4) because i assume (probably wrongly) that contrib maintainers have enough of a clue to be able to understand this Understanding isn't the issue. It's having to remember it, or being slowed down or tripped up by annoying minor inconsistencies. I understand why some command line tools use two dashes for long option names and others use just one, but that doesn't mean I never type the wrong one. ...need to add the right tag, etc, etc). but, in the first instance, i don't think it's too much to ask to understand the basics No, it's not too much to ask, but then it's also not too much to ask for an explanation.
Gary
Derek Wright wrote:
1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0"
2) "DRUPAL-4-7-V-1" and "DRUPAL-4-7-V-1-0"
3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0"
4) "DRUPAL-4-7-REV-1" and "DRUPAL-4-7-REV-1-0"
5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender)
I am almost completely ambivalent between 1 and 4; i lean VERY slightly toward 4 but not enough to care, I could be happy with 4, 1, 2, 3 in that order. =)
Derek Wright wrote:
... well, that's the question... at the talk i gave at drupalcon (http://drupal.org/node/86694), everyone hated using an underscore '_' for this. e.g.:
"DRUPAL-4-7_1" as the 1st development branch compatible with 4.7.x, and "DRUPAL-4-7_1-0" as the 4.7.x-1.0 release tag
there were a few alternatives proposed during the discussion for a different delimiter than '_', such as '-V-', '-R-', '-REV-', etc.
at barcamp, when i had a chance to speak to dries about it, he suggested (and i like) just using '--'. so, here are the viable contenders for branch and tag names:
1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0"
2) "DRUPAL-4-7-V-1" and "DRUPAL-4-7-V-1-0"
3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0"
4) "DRUPAL-4-7-REV-1" and "DRUPAL-4-7-REV-1-0"
5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender) I must be missing something simple. Why isn't DRUPAL-4-7 adequate for the branch? Since there's no expectation of a 4.7.3.1 release, all 4.7 development ought to be on a single branch.
Or is this a result of the idea that DRUPAL-4-7--1 is really going to become either 4.8 or 5.0, but since we don't know yet, it's being called DRUPAL-4-7--1? If that's the case, then why is it necessary to have a number there (since again, there won't be more than one), so that it could be DRUPAL-4-7-NEXT? (Yes, I've asked something similar before, but still haven't seen an explanation of why this wouldn't work.) Aside: From the "For What It's Worth Department," another source control system which I've used has, as a popular convention, the notion that branches are always in lower case, while tags are always in upper case. It's a simple convention, easy to apply, and makes the distinction between branch labels and tag labels visually very apparent. I don't know how folks would react to it, though. I've applied that convention to every subsequent project I've worked on, whether CVS or something else. Gary
On Wed, 4 Oct 2006, Gary Feldman wrote:
I must be missing something simple. Why isn't DRUPAL-4-7 adequate for the branch? Since there's no expectation of a 4.7.3.1 release, all 4.7 development ought to be on a single branch. Or is this a result of the idea that DRUPAL-4-7--1 is really going to become either 4.8 or 5.0, but since we don't know yet, it's being called DRUPAL-4-7--1? If that's the case, then why is it necessary to have a number there (since again, there won't be more than one), so that it could be DRUPAL-4-7-NEXT? (Yes, I've asked something similar before, but still haven't seen an explanation of why this wouldn't work.)
Yes, Gary you are missing that we are talking about *contributions*. A contrib module could have vastly improved new releases even though Drupal has no new release yet. This is why a contrib module could need more releases in the 4.7.x or 5.x space, and this is why it would need possible branches in this space. Goba
Gabor Hojtsy wrote:
On Wed, 4 Oct 2006, Gary Feldman wrote:
I must be missing something simple. Why isn't DRUPAL-4-7 adequate for the branch? Since there's no expectation of a 4.7.3.1 release, all 4.7 development ought to be on a single branch. Or is this a result of the idea that DRUPAL-4-7--1 is really going to become either 4.8 or 5.0, but since we don't know yet, it's being called DRUPAL-4-7--1? If that's the case, then why is it necessary to have a number there (since again, there won't be more than one), so that it could be DRUPAL-4-7-NEXT? (Yes, I've asked something similar before, but still haven't seen an explanation of why this wouldn't work.)
Yes, Gary you are missing that we are talking about *contributions*. A contrib module could have vastly improved new releases even though Drupal has no new release yet. This is why a contrib module could need more releases in the 4.7.x or 5.x space, and this is why it would need possible branches in this space. Thanks, that wasn't obvious. I still tend to think of that sort of change to a contributed module being done in a developer's private sandbox, as well as being a straightforward upgrade, so it wouldn't occur to me that a branch would be needed. I can see how it might be necessary at times (though something I'd try hard to avoid myself).
Gary
On Oct 4, 2006, at 12:55 PM, Gary Feldman wrote:
I must be missing something simple.
yup.
Why isn't DRUPAL-4-7 adequate for the branch?
it is adequate for the default, stable branch, just like we've always used. those branches will continue to work like they always have. however, these other branches i'm talking about are for development and other stable releases of contrib modules that are still compatible with the same version of drupal core's API. for example, read the initial "tagadelic 'backport'" email that started the parent thread... furthermore, rtf-handout. ;) http://drupal.org/files/new_release.pdf if that's not enough, rtf-issue where i first fought for (and won) the argument that we need this in contrib: http://drupal.org/node/58066 in particular, comment #16: http://drupal.org/node/58066#comment-104663 enjoy, -derek
On Wed, 2006-10-04 at 00:52 -0700, Derek Wright wrote:
well, that's the question... at the talk i gave at drupalcon (http:// drupal.org/node/86694), everyone hated using an underscore '_' for this. e.g.:
"DRUPAL-4-7_1" as the 1st development branch compatible with 4.7.x, and "DRUPAL-4-7_1-0" as the 4.7.x-1.0 release tag
there were a few alternatives proposed during the discussion for a different delimiter than '_', such as '-V-', '-R-', '-REV-', etc. *snip*
Derek, do it as you see fit. If you like -- and Dries agrees, go for it. I frankly don't give a hoot what the convention that gets implemented is. I'll read the handbook and do as it says. I would just like the functionality. .darrel.
On Oct 4, 2006, at 3:09 PM, Darrel O'Pry wrote:
I would just like the functionality.
i'm workin' on it. ;) now i just need to conquer 1 last multi-page form and the packaging script, then i'm basically done... -derek
On Wed, 2006-10-04 at 15:24 -0700, Derek Wright wrote:
On Oct 4, 2006, at 3:09 PM, Darrel O'Pry wrote:
I would just like the functionality.
i'm workin' on it. ;) now i just need to conquer 1 last multi-page form and the packaging script, then i'm basically done...
-derek
btw, you're absolutely awesome for doing this.
Darrel O'Pry wrote:
On Wed, 2006-10-04 at 15:24 -0700, Derek Wright wrote:
i'm workin' on it. ;) now i just need to conquer 1 last multi-page form and the packaging script, then i'm basically done...
btw, you're absolutely awesome for doing this.
Seconded!
1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0"
2) "DRUPAL-4-7-V-1" and "DRUPAL-4-7-V-1-0"
3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0"
4) "DRUPAL-4-7-REV-1" and "DRUPAL-4-7-REV-1-0"
5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender)
I think #4 is the least ambiguous. the -- is the most concise, but I am afraid it would not be obvious to new Drupal users, or non-technical users.
Khalid B wrote:
1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0"
2) "DRUPAL-4-7-V-1" and "DRUPAL-4-7-V-1-0"
3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0"
4) "DRUPAL-4-7-REV-1" and "DRUPAL-4-7-REV-1-0"
5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender)
I think #4 is the least ambiguous. the -- is the most concise, but I am afraid it would not be obvious to new Drupal users, or non-technical users. I agree with Khalid here that #4 is the most descriptive. I think having clear CVS tags/branch names is great for new devs as a lot of projects are pretty sloppy with that.
That being said, I'm totally fine with any of those as it's not that big of a deal. Just my 2 cents. -Rob
On 05 Oct 2006, at 00:26, Khalid B wrote:
1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0"
2) "DRUPAL-4-7-V-1" and "DRUPAL-4-7-V-1-0"
3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0"
4) "DRUPAL-4-7-REV-1" and "DRUPAL-4-7-REV-1-0"
5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender)
#1. :) -- Dries Buytaert :: http://www.buytaert.net/
On 05 Oct 2006, at 10:02 AM, Dries Buytaert wrote:
1) "DRUPAL-4-7--1" and "DRUPAL-4-7--1-0"
2) "DRUPAL-4-7-V-1" and "DRUPAL-4-7-V-1-0"
3) "DRUPAL-4-7-R-1" and "DRUPAL-4-7-R-1-0"
4) "DRUPAL-4-7-REV-1" and "DRUPAL-4-7-REV-1-0"
5) "DRUPAL-4-7_1" and "DRUPAL-4-7_1-0" (just for comparison, this isn't a contender)
#1. :)
#1 =P
On Tue, 2006-10-03 at 15:11 -0700, Boris Mann wrote:
On 10/3/06, Derek Wright <drupal@dwwright.net> wrote:
p.s. we could also open up the ability to make a DRUPAL-4-7--N branch right now, and you could commit your code there, even though there'd be no releases packaged up for it yet. that's another option to consider.
I think this is a good idea. Having people test this will perhaps point to any changes that are needed in the rest of the infrastructure.
i think we're pretty much decided on that naming convention (-- as the delimiter between the core API branch and the contrib module's major revision number), so there's no real harm in starting to allow those branches now (unless anyone plans to object to this convention with a better proposal).
No. We are dww slaves. Command us, bird master!
I second the tag without release.... I'd really like to have it and think I've brought it up a couple times before. I think it would be a good interim measure... but then again I'm also cvs retarded some days. just ask killes. ;)
Op dinsdag 3 oktober 2006 22:16, schreef Derek Wright:
so, ideally, you'd just wait for this to go live before you either a) break the stable 4.7 version or b) fork yourself into another module distribution system. use your sandbox for now, and you'll be able to make any DRUPAL-4-7--N branches you want in a few weeks...
This is exellent news! Thanks again for all the hard work, Derek! Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
????????????, Bèr. ?? ?????? 4 ??????? 2006 ?., 14:18:22:
Op dinsdag 3 oktober 2006 22:16, schreef Derek Wright:
so, ideally, you'd just wait for this to go live before you either a) break the stable 4.7 version or b) fork yourself into another module distribution system. use your sandbox for now, and you'll be able to make any DRUPAL-4-7--N branches you want in a few weeks...
This is exellent news! Thanks again for all the hard work, Derek!
Bèr
-- ? ?????????, Dj11 mailto:dj11@1-studio.ru
participants (16)
-
adrian rossouw -
Boris Mann -
Bèr Kessels -
Darrel O'Pry -
Derek Wright -
Dj11 - Иван Одинцов -
Dries Buytaert -
Earl Miles -
Gabor Hojtsy -
Gary Feldman -
inkfree press -
karoly＠negyesi.net -
Khalid B -
Kieran Lal -
Moshe Weitzman -
Rob Barreca