Hey everyone, this is the draft of the roadmap for Dada Mail, let me know what your thoughts are on it,

Cheers,

Justin

Road Map For Dada Mail

Very Near Future,

Goals:

• Release 2.10
• Normalize the release process

At the moment, Dada Mail's release cycles have been tied to the linear fashion that it has been developed:

----> 2.8.12 ----> 2.8.13 ----> 2.8.14 ----> 2.8.15 ----> 2.9----> 2.9.1 ----> 2.9.2

This causes major problems: for example: any bug fixes in 2.8.15 couldn't be released until everything needed in 2.9 was completed. The time between 2.8.15's release (November 17th, 2004) and 2.9 release (May 11th, 2005) was almost four months! That's too long for simple bug fixes to be released. Currently, (August 8th, 2005) we're again going long in the tooth with the release schedule.

This impacts many things, including people's interest in Dada Mail:

• no new releases - no new news of the program
• trust in the program - They won't fix this bug! It's been *months*!
• developing problems - I fixed this bug/added this feature, I think, but I can't test it with the new code, this is useless!

etc,

So, starting with the next release of the program, 2.10, We're going to do have a stable release and then any new work that is feature-related will be for 2.11 - any bugs found in 2.10 will be fixed in its own branch and released as 2.10.1, 2.10.2, etc. Bug fixes will then be merged into the 2.11 release. ie:

  
                                 branch!->/2.10.1 ---- 2.10.x\
                                         /                    \<-merge!
  2.9 ----> 2.9.1 ----> 2.9.2 ----> 2.10/ ---------------------\2.11 
 

This will allow us to release bug fix version, that have no new features added, which will lead to fewer surprises from people that don't like surprises in their software, like ISP's and other people that deploy Lots of software.

What's in store for 2.9.10?

I personally need to release a new version of the program out - whatever's in CVS now, we have to wrap up, go through with a fine-tooth comb for bugs, etc and deliver. Any features that are not ready have to be disabled and put on a TODO for 2.9.11.

I'm hoping that bug releases - ie: 2.10.1, 2.10.2 will come out every 2-3 weeks, as continuing work on 2.11 is done.

This idea isn't novel at any length of the imagination. If I'm talking greek, you may want to brush up on CVS branching:

http://cvsbook.red-bean.com/cvsbook.html#Branches

Questions: Why are we using CVS? Because that's what Sourceforge offers. I'm aware of alternatives - some that work much better than CVS, but none are offered by Sourceforge ATM. This may change.

Here's a more lengthy TO-DO on what needs to be done before 2.10, comments welcome:

• Fix All Bugs (duh)
• Wrap up the CSS/template changes
  * I'd like to template out even more of the HTML for the next release,
  but I'll have to stop, for now
• Document/wrap up new features - which are:
• Global List Sending
  * Dada Mail now has the ability to send to more than one list at one time.
  It's neat. It's basically finished, but needs polish.
  This feature needs a SQL backend
• Global Black List
  * Allows you to share your Blacklist between lists
  * Needs an SQL backend
• Global Unsubscribe
  * Subscribe from one list will subscribe you from all lists
  * Needs an SQL backend
• Batch sending time can now be less than a second
  * Requires the Time::HiRes Perl module - won't be shipped with Dada Mail
  * (requires compilation), but needs to be noted
• Most if not all the features that are allowed in the "Advanced Send a List
  * Message Should be available to "Send a Webpage", meaning:
  * The new Global Sending Widget
  * Perhaps ability to edit the headers
  * Send from a specific point in your list
  * The, "I'm sure", and "Open in a new Window" buttons
• Archives -
  * Wrap up inline image support -
  * Only works with SQL backend
  * Add some sort of editing ability to the message archives - even if it's a message source dump;
  

I'm shooting for this to be done before September. We'll see how it goes.

Very Near Future

Release of 2.11!

Goals:

Much larger changes to the codebase - this is all sort of sketchy, but I would like:

• dada_bridge.pl to be integrated within the rest of Dada Mail
• dada_bounce_handler.pl integrated within the rest of Dada Mail
• Working with these two features made easierer.
• Rest of the HTML out of mail.cgi, perhaps (gasp!) even DADA::App::Errors.pm

Anything else that should be done?

Kind of Far, Future

Release of Dada Mail 3!

I'm, as of now, appending the roadmap I created with some more news, as of the next alpha, the program is going to be branched even before the 2.10 stable release to start Dada Mail 3 -

Goals:

Support for multiple fields in the subscription database

This support will only be for SQL backends -
You may have been noticing a trend where many of the new features are only being supported by the SQL backend. This is for a few reasons:

• SQL is much easier to work with
• SQL is much more efficient to work with
• I'm running out of time (and interest) to work on 3 different Subscriber backends

Saying that, Version 3 of Dada Mail will support a plaintext backend fully and will only require what it needs now to make it work, it just will not be able to do some of the more interesting things that are coming up in the pipeline.

Currently, having all the backends support the same features is leading the program to only support features the lowest common denominator can support. You cannot have a PlainText backend support multiple fields because:

• You'll be rewritting a RDBMS using PlainText Files - which I've come close to doing in past projects - not fun
• Even if you could (and you can, if you're sadistic), the performance would be abismal and buggy.

This is the harder of approaches, the easier of approaches would be to drop PlainText Support completely, but I'm worried that this will eat into the population of people that don't, or don't know how to, work with SQL backends.

So the current roadmap will actually be:

                                                 /3.0 alpha ---- 3.0 beta ---- 3.0 rc (etc)\
                                                /                                           \
                                               /  branch!->/2.10.1 ---- 2.10.x\              \
                                              /           /                    \<-merge!      \
2.9 ----> 2.9.1 ----> 2.9.2 ---->2.10 alpha 1/ ----> 2.10/ --------------------2.11 ----2.x----3.0final!  

Why am working on 3.0 (multiple fields) now?

3.0's (hopefully) only feature difference between the 2.x series will be multiple fields. A client of mine has expressed interest in funding a project that deals with multiple fields and they're funding it now. I do not forsee the source code for 3.0 to be released in any sort of condition until after my project with this client is complete. So, for a while, 3.0 and 2.10/2.11 will be developed in parrallel and merged down the road. I forsee this merge to be extrememly annoying, with many problems :)

Will 3.0 be a complete rewrite of 2.0?

No, but if you glance at 2.0's sourcecode, you'll notice that there's barely any similarity between the code in 2.0 and Dada Mail's current incarnation, so in a sense, we've (well, mostly I) have rewritten the program a few times, in an evolutionary way.

I am hoping that 3.0's development will be funded in some way by the community, since working on basically two open source projects would leave me no time to actually make money to eat :) Saying that, 3.0's release date will most likely coincide with when the proper funding comes in.

Post:
mailto:dadadev@PROTECTED

Unsubscribe:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/u/dadadev/

List Information:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/list/dadadev

Archive:
http://mojo.skazat.com/cgi-bin/dada/mail.cgi/archive/dadadev