twitter/bootstrap — Issue #2258: Version release process
Author: david-proweb
Created: 2012-02-25 19:00:18+00:00
State: open

I know that on Bootstrap README say something like that, but the main focus of this topic is about the launch time of each versions.

Well, I read it from [PHP release process](https://wiki.php.net/rfc/releaseprocess), a method to launch new versions at specific times. I guess that it can be applied to Bootstrap too, for instance:

Considering the version 2.0.1 we have major/x: 2, minor/y: 0, patch/z: 1. (version x.y.z)

* **patch version**: only patches/bug fixes;
* **minor version**: only new features, no patches;
* **major version**: only backward compatibility break, no new features, no patches;

For instance: minor-version (like 2.1.0) only will add new features, not fix bugs. But patch-version 2.1.1 can. The minor-version 2.1.0 will not exist if there are bugs to fix in 2.0.1. If a bug be found by developers on work on minor-version, it need be fixed and launch as patch to current stable version too, before launch the minor-version. So translating: a minor-version should be released without any old bug. If there is to be corrected and released in the current stable version, and then continue the work in minor-version.

#### Timeline

The next step is to launch a new version from time to time:

* **Patch**: launch after one week. If nothing to fix so...
* **Minor**: launch after one week. If nothing to improve so...
* **Major**: launch after one week;

It means that: if the last patch be stable for one week without new patch requests, can work on minor-version. If minor-version be stable for one week, can work on major-version.

#### Legend

* **Patches**: code fix, code feature (mixin only), doc fix;
* **Minor-features**: code new features (like the new badge of 2.0.2);
* **Major-features**: backward compatibility break like remove features or change rule names;

*According to this idea, the badge could only be added in version 2.1.0 and not to 2.0.2.*

#### Branches

We will have two group branches: master (stable) and master-dev. Tags can be used (like currently) to specify the versions. Too we will have a branch for each minor-version (only for reference) like 3.2.1, 3.1.0, 3.0.2, 2.2.3, 2.1.5, 2.0.7. ...

* All major-features need upgrade the major number version.
* All minor-features need upgrade the minor number version;
* All the patches need upgrade the patch number version;

Note that: number versions increases once in a sequential pushes from same request level (major, minor and patch). For instance: push sequentially minor-features increase only one minor version number. If a patch of this new version be fixed after it will be need increase the patch version, what break the minor-feature sequence. So, the next minor-feature push need increase the minor version number again.

#### Upgrade rules

* To upgrade the major version need solve all minor-features requests;
* To upgrade the minor version need solve all patches requests;

For instance: if we have 3 major-features, 5 minor-features and 10 patches-requests on version 2.0.2, we need first fix all patches-requests, creating the 2.0.3. After we have 0 bugfix-requests we can apply the minor-features, solve all and make the new 2.1.0 version. Probably new minor-features and bugfix-requests will be found on this version. We need repeat the last operation again until we have 0 minor-features and 0 bugfix-requests so we can make all major-features and go to 3.0.0.

#### Mastering

After clear some request level, we can merge master-dev to master. For instance: after fix all patches-request of 2.0.2 (turning it to 2.0.3) we can merge on master. After solve all minor-feature request of 2.0.3, we can turn it to 2.1.0 and merge to master.

#### Solving issues

* **Patches-request**: can accept/reject, can't move to next upgrade (only if not important);
* **Minor-features**: can accept/reject and can move to next upgrade (minor or major);
* **Major-features**: can accept/reject and can move to next upgrade (major only);

For instance: if an user suggest a minor-feature like the badge and we are in version 2.0.1, we need first fix all 2.0.1 bugs and then create the suggestion to 2.1.0. But if we have too many good minor-features requests, we need select the more importants to make on the 2.1.0 version. Fix all bugs again, so make the 2.2.0 with the other minor-features accepted (that be moved from 2.1.0 suggestion list).

If an user suggest that the rule ".span1" need be renamed to ".grid1" and it be accepted, it is a major-feature, because will cause some problem with old versions (backward compatibility break). So it need be applied to 3.0.0 version after have 0 minor-feature requests and 0 patch-requests. If this major-feature not it too important, can be moved to 4.0.0 future version or rejected.

#### The end

Well, it is my suggestion about versions. Why it is good? Because some users like to work with stable versions, and I noted that too many bugs remains to very much versions. We (users) don't have total controll about versions and we need live with some bugs (or fix it manually). This method is useful because a new feature only will be launched after ALL bugs be fixed. And a backward compatibility break will exists only if we upgrade to a new major version.

Probabily it not will solve ALL the problem with bugs. For instance: after all patches be fixed and a new minor version be launched, maybe the old version receives a bug. It's more complicated solve that. But it can be fixed on this new minor version and you use that without break your current code. Except to major-versions.

So, some suggestions?