Kunda1 wrote: ↑
Fri Oct 26, 2018 9:18 pm
Started hacking away at Release process
Haven't removed much that was there, added more to it and some structure in the forum of a coarse schedule. What would be useful is having this as a template and then making a duplicate for the 0.18 release that we could strikeout
tasks as we go.
It is good to have such a thing well updated feeding the experiences of this year, so as to optimize it.
I am not sure how much we will be able to optimize this release process, but every 6 months seems to me like an extremely short period. I would try to aim to every 12 months, so a yearly release.
We should have a planned tentative release date (see comment below about the tracker) for the next two versions (today v0.18, v0.19).
I am not sure how to draft it, but I think that we should have a period starting BEFORE the feature freeze, so that devs start looking at the bug tracker more consciously, lets call it "focus period". I have demonstrated to be extremely proficient at procrastinating bug fixing in favour of new features and I cannot reasonably be expected to fix a lot of bugs in 3 weeks, plus those fixing would never be properly tested. I think that a reasonable period is 2-3 months before release. Of course this does not freeze new features, but makes us feel reality and not be surprised by the email with the "feature freeze". It is somehow like this thread starting 3 months before tentative planned release date so that everybody syncs.
The "target release" field of the tracker should be used more, even on bugs that are not assigned to anybody, to mark bugs that we find important to solve before a release, or features we are working on, so others are aware of "how close" we are to release. This appears on the roadmap.
+5. Not that I have 5 votes, but this is much more important than it really appears to and it can be done already now, i.e. checking the bug tracker that every bug and feature has a target release (every release has a date of release associated to it, that it is what I refer above as planned tentative release date, today is set to 31-12-2018 and 31-12-2019 respectively, but I think that in general they should be set a little bit earlier). This ensures the roadmap works properly and nothing major is forgotten.
I have started using the tracker for the Sketcher this way:
1. Every ticket has a target release, including tickets that I know or suspect they are not going to be solved ever, but have important information to reproduce the problem.
2. In principle, all new tickets get the next release, today v0.18. It would be great that the "enforcers" enforce a policy that every new ticket has by default the next release. This makes sure that the developers get to see all new bugs reported until the day before the release date, thus deciding whether to push the ticket to the next release, or to delay the release if it is really major. It should also help the testing period after the "feature freeze".
3. When the "focus period" starts, the list of tickets gets iterated, those that won't be implemented in that release (for example features or bugs that depend on OCCT bugs) are pushed to the next release by changing the target release. This acts like a natural filter, making it clear for everybody via the roadmap
what is not supposed to go in the release.
4. Upon release, all the tickets that did not make it to the release (0.18) and pushed to the next release (0.19).
sgrogan wrote: ↑
Fri Oct 26, 2018 9:47 pm
My opinion is that FreeCAD is released when the release branch is created on github, and it's the packagers job to "catch up" and provide binaries. Others may have a different opinion.
sgrogan wrote: ↑
Fri Oct 26, 2018 10:57 pm
No worries, and I appreciate your effort. I'm just in agreement with @abdullah's concern, a too long feature freeze is counter productive.
I think that 3 weeks from actual freeze to actual release would be about perfect. If this actually means 3 weeks of development freeze.
If we mute into something incredibly efficient and have sufficient man-power and we have all the bugs sorted out at "feature freeze"
, it could even be that we do a full freeze of development in master 3 weeks before the release (0.18), and create a new development branch (0.19) for new features. In such perfect world translations and any bug fix would be merged to both branches, so 0.18 (master) is the one being tested for those 3 weeks, while any new work starts on 0.19. Maybe for version 0.29