I like the general idea, but I think we're not there yet:
If you want to channel our efforts, it's probably more effective if the board appeals to the developers to get some regression/bug fixing done before looking at further feature work or non-essential code re-factoring (it's even in the roadmap if anybody is still reading that). To be honest I'm a bit unhappy with how this is handled in the Inkscape project right now :-/.
Regards,
Eduard
Sounds great to me! I generally use inkscape-trunk for production work to help test, and I'm sure others would appreciate the opportunity. my 2p -C On Sun, Jul 16, 2017 at 7:21 AM, Bryce Harrington <bryce@...961...> wrote:After 0.92.2 is completed, I've been thinking about doing a development release of trunk, to help us build towards 0.93. Something a bit more than just a nightly snapshot, but far less than even an alpha release. Call it an "unrelease" or just a "blessed snapshot". Here's my reasoning for why I think this would be worth doing: a. Our alphas get decent testing, but there's not time for the necessary bug fixing, since we're anxious to get the actual release out. This interim release would stimulate testing and bug fixing independent of any such pressure. b. Moving to gitlab, cmake, and gtk3 has changed a LOT structurally. Doing a "practice release" would help find remaining problems with these transitions. c. Despite all the great work done setting up CI's, automated builds, and rolling packaging systems, many advanced users want a fully usable, QA'd build before they'll look at our work. Lesson learned from last release is that we really need these kinds of users' input on our features before we finalize stuff. d. For the rest of us Inkscapers, it will provide a focal point for our near term development, testing, documentation, and refactoring work. But one that won't need all the rigor that a regular release would have - no about screen contests, overly long feature freeze periods, string freezes, worrying over release-blocker bugs, or needing to polish up release notes and other docs. Procedurally: * A soft feature freeze for a week or two, max * No more than one pre-release (if even that) * Translations encouraged, but no string freeze * Packaging needed for all platforms * Packages available from website, but not linked prominently * Lite marketing - basically just target to advanced users * Is clearly marked UNSTABLE and UNSUPPORTED Some other crazy ideas to consider, that might help prevent it from becoming a support burden: + Annoying popup dialog declaring it so at run time? + No guarantee of file format compatibility? + Limited period for accepting bugs reports? + Expiring binary refuses to run after a certain date? + Advise distros to NOT distribute it? So, your thoughts? Bryce ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel