-
Notifications
You must be signed in to change notification settings - Fork 651
Development process
We target for a new version each two weeks which would include new features or big improvements (X.Y.0). One week after the release, we release another version which would include fixes and small improvements related to the previously released version (X.Y.Z). This makes a release per week.
Priorities are set based on these factors: Number of people requesting a feature, possible impact in the KPI's, value added for existing internal processes, difficulty and availability of resources. Priorities are discussed (and changed if it's needed) during an stand-up meeting that occurs weekly. If needed the discussion will be followed by email. The priority matrix is available here (be sure you enter with your @cartodb email)
Versions are tagged with 3 numbers (X.Y.Z). First number (X) will only change when mayor changes on the software occur. Second number (Y) indicates versions where we incorporate new features or big improvements. The last number (Z) is only being used for versions that only fix bugs and add small improvements related to the actual version.
The day before the release, the release master has to start merging all the branches involved on the targeted release. During this day, people can still work on their tickets but all will have to be fixed before the end of the day. During the morning of the release day, smoke tests have to be passed (Google doc used for this will be named with the date of the release). If all works well, the new version is deployed ASAP. If a version is not ready to be deployed before 6PM, this will be done the following day early in the morning.
The release master is the responsible of merging all the code prior to the release, preparing the Google doc for the smoke testing and tagging the version once it has been deployed.