Qt5-webkit from: https://repology.org/metapackage/qt5-webkit/versions:
Release of 0.18
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Release of 0.18
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
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
Re: Release of 0.18
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.
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
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
Re: Release of 0.18
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.
+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"
Re: Release of 0.18
Of course! These are rough estimates and of course need tweaking from the core-devs. I borrowed heavily from the Scribus project wikisgrogan 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.
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
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
Re: Release of 0.18
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"
Re: Release of 0.18
It is good to have such a thing well updated feeding the experiences of this year, so as to optimize it.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.
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.
+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.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.
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).
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
Re: Release of 0.18
I would argue other way around master becomes 0.19 and a new branch would start for the 0.18 release...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.
Re: Release of 0.18
It may go one way or the other.Jee-Bee wrote: ↑Sat Oct 27, 2018 6:06 amI would argue other way around master becomes 0.19 and a new branch would start for the 0.18 release...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 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.
Re: Release of 0.18
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.
- 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.
Re: Release of 0.18
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.