Hello everyone,
our discussion about the new release process has become somewhat... confusing. That's why I decided to start a new thread to clear things up a bit. The opening post will contain the results of our discussion.
In my opinion this should include...
- our current team members and their tasks.
- a breakdown of our release process into stages incl. appropriate time frames.
- the actual release process with all its actions and dependencies.
--------------------------------------------------
--------------------------------------------------
------------- My first diagramm --------------
--------------------------------------------------
--------------------------------------------------
Best regards,
Atahualpa
Update: I hope this makes things a bit more clear.
Atahualpa wrote:Let me elaborate on this. There are five phases per release cycle:
1. Development Phase
The longest and (development-wise) most productive phase; lots of bugs get fixed, some features get implemented. Our release builders do their nightly builds and everyone is free to test them. They have to find them on their own though.
2. Pre-Release Phase
This is just an intermediate stage of the release process to make everyone aware of the upcoming release, inform the release manager, our packagers and testers, and let the video producer know that he can start to sketch out the release videos. Its main purpose is to allow everyone to adjust their time schedules, so nobody gets caught off guard. Ideally, we are feature-complete for the release by then.
3. Release Phase I
After that, the release tag is created which marks the beginning of the actual release process. The packagers build their RCs and link them to the release thread, testers start to look for problems with the installers -- but also for game-breaking bugs and stuff. The roadmap gets cleared of unsolved issues, the video production starts.
4. Release Phase II
This is the last signal for the release process. The release date is set to exactly 14 days after the appropriate announcement of this phase. This way, people know when the release is to be expected, and the release team knows when their work has to be done. We could as well create a timer/countdown at our homepage.
This is not meant to put any pressure on certain members -- and, in case of emergency, we can delay the release -- but it should greatly improve our communication. Of course, we only enter this phase if their are no major problems with the builds.
The packagers switch their terminology to "Release Build" (or something like that), the changelog is set up, the video review process starts, and final adjustments are made, if necessary.
5. Post-Release Phase
After the release, we need some time to clear everything up: The Outreach needs to be updated, many questions as well as feedback from the community are to be expected, the Wiki needs to be updated -- and, above all, we have to agree on the new roadmap, i.e. we have to (internally?) discuss the goals for the next version and set up the new (internal) release thread and schedule.
Once we have finished this "cool-down" phase, the (public) release thread for the next version is created.
Essentially, the division into several release phases is mostly a matter of communication and scheduling.