Release roadmap

Some thoughts about that list.

A demo site is IMHO nice to have but certainly not a requirement for a stable release. It would also require quite a bit of work e.g. in the mail log module to properly deal with HTML mails to actually have a useful output. I also still think a demonstration video would be a more useful introduction to this module as it allows to show off the relevant features much easier (like theming, which you can't do on a demo website).

From looking at your smaller features list, we need to define what exactly "stable" means for us I guess. The strict, core-inspired meaning of stable means not only no API changes but also no UI changes and no string changes. This rules out most of the issues in your list, however :)

Last, I think the batch API stuff should actually be fairly simple and won't require any architectural changes. All we need to do there is setting up the batch array with n calls to simplenews_mail_spool() (a wrapper function that does that, actually) and a final status update callback and we're good.

Yes, documentation is important. It's not necessarly a release blocker though (e.g. we don't necessarly need complete documentation of everything to do a stable, but it should be as good as possible).
BTW, I added Simplenews to my personal api documentation site: http://api.worldempire.ch/api/simplenews/functions/7-1. As you can see, that needs a bit of work too. I we should at least create a few groups (e.g. hooks, API functions (maybe separate loading/saving stuff and a separate group for sending stuff) and list them on the front page. See http://api.worldempire.ch/api/privatemsg for an example.

Yes, fully agreed that batch API isn't a replacement for our mail spool. But it should be easy to add proper batch processing on top of it. Search API is by the way very similar. They maintain their own progress tables (a table that lists all entities including a flag to tell if something needs to be indexed/re-indexed) and have recently switched to using the queue and batch systems on top of that. Basically, what they did is a) instead of processing directly on cron, they just created queue items, each a search process over n entities (= sending n mails) and these are then processed by core. The advantage is that core then does the time management by processing these queue items until time runs out. And they added batch API to process them through the UI. They didn't get it right initially, there was some confusion in the UI regarding items that were added to the queue (they weren't listed as indexed nor was it possible to index them manually). So we might be able to learn/adapt from their code.

Re demo site, I'm fine with adding one of course, I'm just not sure what can be seen there then. How to show off confirmation mails for example, or HTML mails, without accidently revealing the mail address of users who use their real address for testing purposes and so on... The main things to see are the newsletter/subscriptions/category user interfaces, things that aren't exactly awesome right now :)

Split doc, move queue, new issue

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Just wondering. That list of Long term features planned for simplenews. It takes it quite far from being "simple" newletters and into a pretty much full blown newsletter system.

Is that what you want simplenews to be?

I'm asking this because I'm working with the Party Module making CRM for Drupal and we're trying to figure out how we should do our Mailing system aspect of CRM. We're definitely going to want some support for Simplenews but for the more advanced features (like bounce support) I'm wondering if we should try and so something else (like our own system, or php-list, etc) or put some time and effort into improving simplenews.

Yes, we are interested in making it a full blown newsletter system I guess. The name Simplenews is quite old and I don't think the module is simple anymore already :) Simple can also have many meanings, we *do* try to keep it simple and easy to install/use but at the same time pluggable and extendable.

In the case of bounce handing, the idea there is that another module deals with bounces and notifies us (or a glue/bridge module hooks into the generic bounce handling and notifies us).

In short, we're interested in working together.

Integration with http://drupal.org/project/unsubscribe would be fab :)

Also, the newsletter opt in could be made a user entity boolean field :)

Just wondering. What is status on 7.2 release? Would really need the fieldable subscribers for my project and as far as I check it is included only in 7.2.X-Dev release (for 2 years already). I didn't manage to find any information regarding 7.2 release expect that it is used as the version for 8.x port. Is it "stable" enough to use if I need those extra features, what is ETA of alfa or beta.