>
> > I understand that things will break/shift around/change, but dropping
> > existing
> projects seems like throwing the baby out with the bathwater.
Vesa said he was going to break backwards compatibility for 2.0 and there
has been an overwhelming amount of push-back on that statement.
What is important to understand is that backwards compatibility is not
first and foremost in the current 2.0 design plans because it is an
obstacle which can hurt progress.
This doesn't mean 1.x projects won't play in 2.0. We have some very skilled
resources active on our development team that will do what is possible to
upgrade 1.x projects to 2.0 projects.
Some portions of the project will be lost, namely some automation track
information if it proves too difficult to upgrade.
But we have every intention of making 1.x projects playable. For those
that upgraded from 0.4.x to 1.0.x you probably noticed quite a few places
where the old project didn't play correctly. This stuff is going to happen
from version to version and we take the good with the bad. It is part of
progress.
But a reminder, this topic is more about how we track our bugs. Our 2.0
initiatives have email threads and futuremaps which would probably be a
better place to stir up the compat conversations.
- [email protected]
On Wed, Jan 28, 2015 at 7:50 PM, Phil (list) <[email protected]> wrote:
> 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
