|
Release Engineering
This document details the process required
to release a new version of the software. As our project is starting, this set of
standards may change to acommodate to developers needs, so, this document in no way is finished,
but it gives a starting point so active developers know what to do and when to do it. With this,
we can be able to make at least a release every week.
The process of releasing a new version starts every sunday, in this day, project leader maxim assisted by bromer will:
- Add to (Features Requests or Bugs) tracker a non-organized list of things to do (also to CVS in TODO file)
- Each of the developers pics a task and assigns the task to himself in dev area - This is how we track it
- When the task is complete, you clear your TODO file, tracker, and task
By the end of the week, around Thursday or Friday, we need to do some testing so:
- The rest of the developers, and preferably non-developers, test cvs builds anf give feedback to our developers so they can
fix the bugs and release a new version almost by Saturday
- In the future some kind of Release Candidate should be released on Thursdays and Fridays so we can have more feedback from
people not tracking cvs
- Optionally, a version tested succesfully, can be released before the Thursday-Friday deadline. This is for the cases when
nothing serious is on the list waiting for the planned deadline.
Exceptions can be only major changes, These might want to get a different organization.
As a rule, one should think -
"the fresher the application is, the more quality we add"
|
