Difference between revisions of "Developer Meetings/20170915"

From Slicer Wiki
Jump to: navigation, search
(Created page with "{{mbox | type = style | text = If you would like to list your topic here, create a wiki account and [{{fullurl:{{FULLPAGENAME}}|action=edit}} edit this p...")
 
 
(5 intermediate revisions by the same user not shown)
Line 28: Line 28:
 
   
 
   
 
</pre>
 
</pre>
 +
 +
== Conclusion ==
 +
 +
* 4.7 release: After addressing
 +
** [https://discourse.slicer.org/t/interpreting-cdash-reporting-extension-is-packaged-despite-build-errors/856/4 extension packaging]
 +
** and [http://slicer.cdash.org/viewBuildError.php?buildid=1079946 numpy issues],
 +
** update of DCMTK
 +
* we will create the release. In the next 2 weeks
 +
 +
* Update [[Documentation/Nightly/Developers/Versioning#Slicer_Package_naming_scheme|versioning scheme]]:
 +
** 4.7 -> current dev
 +
** 4.8 -> release
 +
*** slicer-4.8 -> maintenance branch for 4.8 release
 +
** 4.9 -> +1 dev
 +
** 5.0 -> +1 release
 +
*** slicer-5.0 -> maintenance branch for 5.0 release
 +
** 5.1 -> +2 dev
 +
 +
 +
* Use of <code>backlog</code> target release in mantis: We associate it with non critical issues
 +
 +
* Transitioning issues to GitHub:
 +
** We wouldn't need to migrate the issues
 +
** Issue would be migrated as needed
 +
 +
 +
Action items:
 +
* announce release on discourse: will be in "release" mode. Avoid major "breaking" changes
 +
*

Latest revision as of 15:23, 15 August 2017

Home < Developer Meetings < 20170915


Updates

To discuss

  • Schedule for the next release

From Andras:

The main question is when to release the next stable version. RSNA seems to be a bit late:

1. We would need a solid version for MICCAI (Sep 9), it would be nice to do it with a “stable” 
version than a hand-picked nightly,

2. We may not want to delay Qt5/VTK8 migration until November.
 
Starting to stabilize the nightly now (fix important errors, refrain from integrating risky changes), 
releasing a stable version by the end of August (before MICCAI), and create releases as needed (before RSNA) would make sense.
 

Conclusion

  • Update versioning scheme:
    • 4.7 -> current dev
    • 4.8 -> release
      • slicer-4.8 -> maintenance branch for 4.8 release
    • 4.9 -> +1 dev
    • 5.0 -> +1 release
      • slicer-5.0 -> maintenance branch for 5.0 release
    • 5.1 -> +2 dev


  • Use of backlog target release in mantis: We associate it with non critical issues
  • Transitioning issues to GitHub:
    • We wouldn't need to migrate the issues
    • Issue would be migrated as needed


Action items:

  • announce release on discourse: will be in "release" mode. Avoid major "breaking" changes