[development] tagadelic 'backport' for 4.7

[Derek Wright]

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).