On Wed, 2015-01-28 at 21:57 -0200, Amadeus Folego wrote: > On Wed, Jan 28, 2015 at 05:58:06PM -0500, Phil (list) wrote: > > 1) Offering a lint check of sorts when opening an existing file that > > would flag (either a dialog pop or writing out a log file) things that > > aren't compatible giving the user an indication of what is going to > > break and giving them an opportunity to rework those parts of the > > project since they'll (hopefully) be better equipped to decide the best > > way to 'fix' things. > > This looks like a sensible idea. > > > Are the changes planned for 2.0 really so radical that existing projects > > can't be migrated or could a 1.x release be set up as a springboard to > > 2.0 that could help with migration? > > Major version numbers in software development most of the time means > compatibility breaks, although this may not be the case some times. > > It's really a crazy thing, but if we are going to break stuff we need to > give a good reason for this, that's why it's very important to create > features/improvements/add support in a way that users really feel that > the migration is worth it. >
I understand that things will break/shift around/change, but dropping existing projects seems like throwing the baby out with the bathwater. One of the nice things about persisting things in an external file format is that sweeping code changes can be made without breaking everything from the users POV: they'll start up the new version but their stuff will still be there. Granted, it's more work than just breaking everything, but once you go down the path of tossing their data there's a significant goodwill cost involved. > > 2) Assuming they've iterated through 1 and done everything they can or > > plan to in preparation for 2.0, provide a 'save as 1.x final' or > > whatever to save out the streamlined project which would drop on the > > floor any incompatibilities providing a smaller footprint / feature set > > for 2.0 to deal with from a migration standpoint. > > Again, very good ideas, maybe you can help us on github even if you > don't code? > I code, but my C++ is rusty (basically means I can help, but my productivity will be limited initially.) I'm game for pitching in where I can which is part of why I brought this up. > You can add issues describing feature requests or bug reports. > > Specifically for 2.0: we are not yet officially on 2.0 development > effort, as soon as we understand the breaking changes and see them we > can see if this is possible. Fair enough. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
