-
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, how something improves how the CartoDB development is being done, value added for existing internal processes, difficulty, how different makes something our product to our competitors's products, how passionate do we are about it, 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)
About the Priority Matrix
All edits must be done in the 'All Features' sheet. There a new row will be added per each new feature which will be scored based on the different parameters. The top sheet is basically showing all the non implemented features ordered by score.
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 and referenced in the releases list correctly. If a version is not ready to be deployed before 6PM, this will be done the following day early in the morning.
Release master?
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.