Road Map For Dada Mail


Very Near Future

Release of 2.11

2.11's main feature will be an overhaul of the mass emailing routines. The problem with the current sending routines is that there is no meta information saved about the sending process, thus, if/when a problem does occur during the process, there's no way to automatically pick up the mailout. This is further made delicate, because in Dada Mail, it's a one shot thing - a mailout starts, and if it doesn't finish, it doesn't finish. This is a really bad spot to be.

This needs to be addressed before the multiple fields project (Ver 3.0, basically)

Some more details:

Problems:

So, I propose the following changes, which are all quite dramatic:

Currently, a mailing list message is sent by first making a temporary list of all the subscribers and some extra meta information to fill in some of the tags - to personalize the message, in other words. This is great and we're going to keep this file around.

What's going to change is the addition to a few new files:


Near Future

Release of Dada Mail, version 3.0!

Dada Mail, version 3.0 will be basically Dada Mail with multiple subscriber fields support. This seems like only one small feature, but it affects every part of the subscription process, it affects how mass mailings are created, how you administrate the list itself, most everything, except, perhaps archiving. Big. Deal. Very big deal.

Also, if you want to look at the 4+ history of the Dada Mail 2.x serious, you'll notice that the program is entirely different than it was when released as 2.0 - it's basically has been rewritten a few times, in chunks. So it goes.

For more information on multiple subscriber fields and Dada Mail, see:

http://mojo.skazat.com/features/multiple_fields.html

More information will be released as the feature gets fleshed out.


A Future, Far Far Away

Or, things we really really want to work on, but haven't had time/money (commission us!!!) to get to work on.

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:

etc,

What should happen is a scenario like this:

There should be a stable release and then any new work that is feature-related will be for the next major release - any bugs found in the last major release will be fixed in its own branch and released as x.x.1, x.x.2, etc. Bug fixes will then be merged into the next major release release. For example:

  
                                 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.

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.

Program-specific stuff

Goals - improvements to current stuff:

Documentation

After the 2.10 release, I'd like to talk more about moving some or most of the documentation into a Wiki that can be edited by anyone. This will stop old lazy bones here to hold up the availability of documentation to the project and give us another thing to play with.

I probably need someone to step forward as an editor.

Anything else that should be done?