Release of 0.18

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Release of 0.18

Post by Kunda1 »

yorik wrote: Fri Oct 26, 2018 2:33 pm From my point of view, qt5 integration seems now basically complete, and I believe the missing components (qt5 webkit, etc) have now found their way into all main distros. We should check on Fedora and Ubuntu for pyside2, though.
Qt5-webkit from: https://repology.org/metapackage/qt5-webkit/versions:
Image
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Release of 0.18

Post by Kunda1 »

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.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Release of 0.18

Post by sgrogan »

Kunda1 wrote: Fri Oct 26, 2018 9:18 pm Started hacking away at Release process
wmayer or yorik will announce a feature freeze.
The 3 week schedule is the issue, we'd like it to be this way but historically it takes longer.

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.
abdullah wrote: Fri Oct 26, 2018 1:39 pm On the other hand, from a practical point of view it is not very interesting to stop the development of new features for a long period (one month would be ok, two months is probably too much, as it stops development).
+1, this is an opportunity for improvement for the FreeCAD project. I'm not sure how to fix it but we aim for earlier than the earlier and accomplish later than the latter.
"fight the good fight"
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Release of 0.18

Post by Kunda1 »

sgrogan wrote: Fri Oct 26, 2018 9:47 pm wmayer or yorik will announce a feature freeze.
The 3 week schedule is the issue, we'd like it to be this way but historically it takes longer.

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.
Of course! These are rough estimates and of course need tweaking from the core-devs. I borrowed heavily from the Scribus project wiki :D
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Release of 0.18

Post by sgrogan »

Kunda1 wrote: Fri Oct 26, 2018 10:44 pm Of course! These are rough estimates and of course need tweaking from the core-devs. I borrowed heavily from the Scribus project wiki :D
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 am worried about OSX support. It seems the team has shrunk back to peterl94 and I don't know how to help.
"fight the good fight"
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Release of 0.18

Post by abdullah »

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" :ugeek:, 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 :lol:
Jee-Bee
Veteran
Posts: 2566
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Release of 0.18

Post by Jee-Bee »

abdullah wrote: Sat Oct 27, 2018 3:40 am 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.
I would argue other way around master becomes 0.19 and a new branch would start for the 0.18 release...
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Release of 0.18

Post by abdullah »

Jee-Bee wrote: Sat Oct 27, 2018 6:06 am
abdullah wrote: Sat Oct 27, 2018 3:40 am 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.
I would argue other way around master becomes 0.19 and a new branch would start for the 0.18 release...
It may go one way or the other.

I prefer the former because I understand that a release as a tag of the master branch, so my rationale is this:

One could think that master is stall waiting for translations and so on to be merged, then it is tagged as 0.18_release and the release generated. Under this rationale 0.19 branch is a preliminary development of the next cycle that gets merged after the tag/release.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: Release of 0.18

Post by looo »

For a release with py3 I think we need to check and fix at least 4 wb's:

- draft
- arch
- fem
- path

I can't do this, because I am not very familiar with these wb's... So please @yorik, @sliptonic, @bernd try to get ready for py3! Py3-ignorance must finally come to an end.
peterl94
Veteran
Posts: 1001
Joined: Thu May 23, 2013 7:31 pm
Location: United States

Re: Release of 0.18

Post by peterl94 »

FYI, the project at work that is taking up all my time and brain space has a deadline of Jan 1st, so as long as 0.18 is released after that, I’ll have time to get the macOS situation in order.
Post Reply