Voting starts in March for the Drupal Association Board election.
Security releases of Drupal core and contributed projects currently use the normal version numbering scheme, with no special indication in the release number that a security fix is included.
The reason this approach was taken is that there is a large chunk of code that has a dependency on these version numbers, including Update Status and Update Manager modules in 6.x and 7.x, Drush, localize.drupal.org, the release packaging system, and so on.
A disadvantage of this approach, of course, is that it's not immediately clear which release is which. However, keep in mind that this information is readily available from the release notes (notice the "Security update" tag on the Drupal 7.1 release notes, for example) as well as from the list of security advisories for Drupal core and contributed projects and various other places, such as the Update Manager module within your Drupal site.
Security release "windows" are every Wednesday for Drupal contributed projects, and one Wednesday a month (usually the third Wednesday) for Drupal core.
A release window does not necessarily mean that a release will actually be made on that date, but it exists so that site administrators can know in advance which days they should look out for a possible security release. (Also, in the unusual case of a highly critical security issue, such as one which is being actively exploited in the wild, releases may be made outside of the normal window.)
Security releases happen between 12 noon and 5pm Eastern time.
For Drupal core, the current policy for security releases is that they occur on a different date than the monthly bug fix/feature release window:
- Bug fix/feature release window on the first Wednesday of the month
- Security release window on the third Wednesday of the month
Whenever a security release is created, it contains just the security fixes applied to the previous Drupal core release. The next bug fix/feature release, when it happens, will contain the previous security fixes plus all other fixes in the branch to date.
This approach is intended to allow site builders to upgrade immediately once a security hole is found, without the difficulty of wrangling patches, and without the terror of accidentally breaking their sites by pulling in other upstream changes that have not been widely tested yet.
Currently, at least, Drupal contributed projects may not always follow the above policy. For example:
- There may be still be two releases (a security release and a bug fix/feature release) but with both released on the same day. (Up until October 2012, Drupal core did both on the same day also.)
- Or, there may be only one release, which contains both the security fix and bug fixes/features together, and which may therefore require more careful testing before it is deployed to production websites.
You can always check the release notes for a particular security release for more information about what exactly it contains.