Author Topic: Removing the last Ver 1.X update.  (Read 1620 times)

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,583
  • Kudos: 92
    • KulpLights.com
Re: Removing the last Ver 1.X update.
« Reply #15 on: January 12, 2019, 07:00:07 AM »
As Bwinter said, if you want to stay with old version of FPP, stick with old version of xLights and Windows and all that as well so everything works to together.


We are NOT Microsoft, we don't have a huge team of people dedicated to testing and maintaining compatibility with ancient versions of everything we've ever released.  Quite the opposite.  It is a huge burden on us, VOLUNTEERS, to try and keep things working with ancient stuff.   At this point, maintaining any bit of compatibility with 1.x is more effort and time than it's worth.   People need to move forward. 


There is a very good chance that by the time we start setting up shows later this year, (likely the June/July images), FPP will not detect or multisync with 1.x version.   xLights may not auto-upload to 1.x images.  etc..   I'm not saying it's 100% set, but it's certainly "more likely than not". 




Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,420
  • Kudos: 45
Re: Removing the last Ver 1.X update.
« Reply #16 on: January 12, 2019, 07:51:34 AM »
We are NOT Microsoft, we don't have a huge team of people dedicated to testing and maintaining compatibility with ancient versions of everything we've ever released.  Quite the opposite.  It is a huge burden on us, VOLUNTEERS, to try and keep things working with ancient stuff.   At this point, maintaining any bit of compatibility with 1.x is more effort and time than it's worth.   People need to move forward. 

Dan and Chris, I very much appreciate everything  you (and other developers) do!   I think its all fantastic and I look forward to all the new features and updates. 8)

In your defense, I would like to add that we were first told about changes for v2.x in 2017 (two years ago) but to play it safe, you held off on releasing anything until after Christmas 2017.  Early in 2018 (about this time last year) V2.x beta was announced and offered up for testing by the general community.  I jumped on board right away.  Sure, there were bumps along the way.  Changes needed to be made and I had to adapt some things.  But it was early in the year and gave us end users plenty of time to test and play and adjust to the changes.

Now, here were are almost TWO YEARS LATER (plenty of time) and you (rightfully) decide to stop supporting V1.x and push forward with V2.x new features and enhancements.  I applaud you and support the decision. As far as I know, nobody has paid for your support (and you have given LOTS).  Anybody out there who is concerned about the support of your FREE SOFTWARE needs to consider how much (or how little) they have paid you for that support  before complaining about your choice to stop supporting older, outdated versions.  ::)

Keep up the GREAT WORK and THANK YOU for all you and Chris have given to this community  :)
« Last Edit: January 12, 2019, 08:10:12 AM by pixelpuppy »
-Mark

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: Removing the last Ver 1.X update.
« Reply #17 on: January 12, 2019, 08:53:06 AM »
It's not out of the ordinary for people to use open source products in commercial applications.  There's plenty of companies out there selling VoIP PBX systems based on the free and open source Asterisk software.  There's big money in that.  There's tons of commercial products on the shelves that use Linux at the core, and have many FOSS software packages in them like apache, MySQL, MyPHP, etc... 

Maybe many people don't realize it, but money does change hands with software like this.  I don't expect that it's required, but if you need some help quickly, or need a new feature added on a specific timeline, especially when it's for a paying client, then I feel it's only fair to pay the developers for it.   I doubt that I'm the only one who's paid them.  I know the xLights and Vixen teams get a fair amount of donations/payments as well.  We don't expect it, but we appreciate it.  Especially when it's coming from people that we know are making money with it.

Yes we'd been hearing about 2.0 for a long time.  But honestly many of us had no idea what that was going to mean.  I expected 2.0 to have a new UI and internal API separating the UI from the engine.  That didn't happen.  I know it has the new playlist system, and new stuff at the output stage.   I'm not really sure what the major feature was that warranted the major version change.  I guess it was the underlying OS change.  I would expect though that if any of the current functions or file formats change, or stop working, that wouldn't happen until the next major version.  And i don't think it's unreasonable to expect that everything can be seamlessly migrated forward to the new version.


As most of you know, I'm one of the leads on the Vixen team.  We're constantly conscious about how new features and changes will interact with existing profiles and sequences.  While we don't allow you to bring your content from a newer version to an older version, we do make sure all of your existing stuff just works on each new version.  In most cases it just works.  Occasionally we need to migrate the sequences/profile forward.  In those cases, we do it automatically when you open it in the newer version. Prompting first to give you the chance to make sure you have a copy of the old version if you need it.  We never make any changes that will affect compatibility within a major release cycle, those only come at the annual major release.  This often means that we have a new feature that's ready to go in november or december, but it doesn't get merged until after Christmas to maintain the stability of the main project at the most important time of the year.  I'm not saying every project needs to do it this way.  But it does work well for us.  The most important part of it is establishing a pattern the users can rely on, and then sticking to that. 



Offline Bwinter

  • Sr. Member
  • ****
  • Join Date: Jul 2016
  • Location:
  • Posts: 434
  • Kudos: 10
    • First Show 2016
Re: Removing the last Ver 1.X update.
« Reply #18 on: January 12, 2019, 09:20:46 AM »
While we don't allow you to bring your content from a newer version to an older version, we do make sure all of your existing stuff just works on each new version.

And thats precisely whats about to happen:  the new version (of xLights) wont work with the old version (of FPP).

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: Removing the last Ver 1.X update.
« Reply #19 on: January 12, 2019, 09:35:24 AM »
While we don't allow you to bring your content from a newer version to an older version, we do make sure all of your existing stuff just works on each new version.

And thats precisely whats about to happen:  the new version (of xLights) wont work with the old version (of FPP).
What I had in mind when I said that was the need to manually reconfigure the outputs when moving to 2.0.  I know the schedules and playlists moved forward with a convert button, but the outputs require a manual redo.

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,420
  • Kudos: 45
Re: Removing the last Ver 1.X update.
« Reply #20 on: January 12, 2019, 10:16:35 AM »
we do make sure all of your existing stuff just works on each new version.  In most cases it just works.  Occasionally we need to migrate the sequences/profile forward.  In those cases, we do it automatically when you open it in the newer version. 

And in your defense, that is something I have always admired about Vixen over xLights.  I use both.  There have been updates to xLights that made older versions obsolete without any migration tool.  Vixen has always been very good about making sure that if any new change is going to be incompatible with older sequences that a migration tool is built-in and usually fully automatic.  That does give it a much more professional and commercial type of feel to it and I do appreciate that aspect. 

It seems to me, as Bwinter pointed out, its the new version of xLights that is breaking things, not the new version of FPP.   The new version of FPP will still read old V1 fseq files.  Its totally understandable that the old version of FPP will not read new V2 fseq files.   Users who want to stay on the old version of FPP should stay on the old version of xLights .... OR ... they could switch to Vixen   ;D
« Last Edit: January 12, 2019, 10:39:52 AM by pixelpuppy »

Offline Bwinter

  • Sr. Member
  • ****
  • Join Date: Jul 2016
  • Location:
  • Posts: 434
  • Kudos: 10
    • First Show 2016
Re: Removing the last Ver 1.X update.
« Reply #21 on: January 12, 2019, 10:26:19 AM »
I still curious, what scenario would absolutely forbid someone from upgrading FPP (versus I dont want to)?  Granted, upgrade cant be performed remotely, and does require physically access to the Pi (and I understand that is challenging if your unit is on a snowy roof in the middle of our display season).

But what scenario would prevent someone from having access for the next 6 months or so?  Do you have your landscape controller buried in the crawl-space somewhere?

Offline algerdes

  • Supporting Member
  • ******
  • Join Date: Apr 2014
  • Location: Lebanon, Illinois
  • Posts: 891
  • Kudos: 13
Re: Removing the last Ver 1.X update.
« Reply #22 on: January 12, 2019, 10:31:01 AM »
Ding, Ding, Ding.  Everyone back to their corners!   ::)


Sequencers: Vixen3 and xLights
Players: FPP and xSchedule Controllers:  Renards - SS24/SS16; E1.31 - San Devices E682 - Falcon F16, F4, F48 - J1Sys - DIYLEDExpress E1.31 Bridges.  Much more!

Offline Bwinter

  • Sr. Member
  • ****
  • Join Date: Jul 2016
  • Location:
  • Posts: 434
  • Kudos: 10
    • First Show 2016
Re: Removing the last Ver 1.X update.
« Reply #23 on: January 12, 2019, 10:51:26 AM »
I seem to recall a coming feature where the Master can upgrade all the Remotes.  Does this require that all the Remotes at least be FPPv2.x?  Or will this be a method that allows remote-upgrade?

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Re: Removing the last Ver 1.X update.
« Reply #24 on: January 12, 2019, 11:24:54 AM »
I seem to recall a coming feature where the Master can upgrade all the Remotes.  Does this require that all the Remotes at least be FPPv2.x?  Or will this be a method that allows remote-upgrade?

The feature is to allow remotes to be updated from the master so the remotes don't need Internet access.  In reality, any system on the network could be the 'update master', because of the way the version control software git works.  You can clone/update a repo from another repo and that's what the recent patch allowed.  Basically, you tell the remote to pull in its updates from another system rather than github.com.

Since we now have version information in the MultiSync screen, it would be fairly easy to add buttons to the page to allow you to trigger updates from one place to make sure all systems are on the same version.
-
Chris

Offline Bwinter

  • Sr. Member
  • ****
  • Join Date: Jul 2016
  • Location:
  • Posts: 434
  • Kudos: 10
    • First Show 2016
Re: Removing the last Ver 1.X update.
« Reply #25 on: January 12, 2019, 11:28:57 AM »
So basically, this would allow a person to upgrade from pre-2.x remotely (without needing physical access to the Pi)?

Offline jchuchla

  • Sr. Member
  • ****
  • Join Date: Jul 2014
  • Location:
  • Posts: 355
  • Kudos: 1
Re: Removing the last Ver 1.X update.
« Reply #26 on: January 12, 2019, 11:34:39 AM »
I still curious, what scenario would absolutely forbid someone from upgrading FPP (versus I dont want to)?  Granted, upgrade cant be performed remotely, and does require physically access to the Pi (and I understand that is challenging if your unit is on a snowy roof in the middle of our display season).

But what scenario would prevent someone from having access for the next 6 months or so?  Do you have your landscape controller buried in the crawl-space somewhere?

I don't think anything would absolutely forbid someone from doing an upgrade.  It's a question of value.  Is the new version worth time and effort required to do the upgrade.  On larger shows/installations in particular, that time and effort will greatly increase.

For me, distance is the biggest deal.  And it's only really the upgrades that require reimaging.  What value does the new version bring to the table that justifies a flight out to the site.  On occasion, I have been able to just send out a new card that's ready to go and have someone swap it onsite.  But sometimes that's iffy, depending on the required steps that follow.

For the stuff in my own yard, i can understand that something is just not worth doing.  I've got one FPP instance inside of my Tune-To sign.  To change the card requires that i bring my whole sign inside, and lay it flat on its face and break the seal to remove the back panel to get to the Pi.  And putting it back together requires resealing it.  The whole process would take more than a day.  I realize this is a problem of my own making.  But it's frustrating that some upgrade in another part of the display may require me to spend several hours on getting that sign FPP upgraded just to keep working the same as it always has.

I'm curious why certain versions (especially the early 2.x builds) require full reimaging.  I can accept that a full OS upgrade may require a reimage.  But why do versions within the same OS require a full reimage?  Can't the packages and dependencies be upgraded in place via scripts? 

As a comparison with other Pi based applications, I've had 2 OSMC Pis running in my house for many years.  I've never had to reimage them since they've been first installed.  They get upgrades almost monthly, sometimes adding some rather major features, but never required that I remove the SD card to upgrade them.  And I've never had to reenter configuration data.  I don't know that dev-team nearly as well as the guys here, but it seems like they've also only got 2-3 developers on that project.

Of all of the features and functions of the FPP, the most sensitive to change are multisync and fseq file format with output config of existing types being close behind.  It's completely understandable that new features will require additional configuration and perhaps extensions in the format.  But the old stuff should still with with the new.


Oh, and I totaly didn't mean to start a Vixen/xLights comparison.  It was more of a statement that migrating legacy stuff is more important that we want it to be as developers, but it's very important nonetheless and something we can't ignore. 

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,583
  • Kudos: 92
    • KulpLights.com
Re: Removing the last Ver 1.X update.
« Reply #27 on: January 12, 2019, 11:35:40 AM »
So basically, this would allow a person to upgrade from pre-2.x remotely (without needing physical access to the Pi)?


No.   There is no way to update from 1.x to 2.x without re-imageing.   This will allow going from 2.6 to 2.7 without having the remote Pi's be on a network that has internet access.

Offline Bwinter

  • Sr. Member
  • ****
  • Join Date: Jul 2016
  • Location:
  • Posts: 434
  • Kudos: 10
    • First Show 2016
Re: Removing the last Ver 1.X update.
« Reply #28 on: January 12, 2019, 11:38:38 AM »
So basically, this would allow a person to upgrade from pre-2.x remotely (without needing physical access to the Pi)?


No.   There is no way to update from 1.x to 2.x without re-imageing.   This will allow going from 2.6 to 2.7 without having the remote Pi's be on a network that has internet access.

Thats what I suspected, but just wanted to clarify

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,583
  • Kudos: 92
    • KulpLights.com
Re: Removing the last Ver 1.X update.
« Reply #29 on: January 12, 2019, 11:43:30 AM »

I'm curious why certain versions (especially the early 2.x builds) require full reimaging.  I can accept that a full OS upgrade may require a reimage.  But why do versions within the same OS require a full reimage?  Can't the packages and dependencies be upgraded in place via scripts? 


They didn't REQUIRE re-imageing for the most part.   My TuneTo sign and one of my other controllers is still using the 2.0 image.   The "Upgrade" button is all I've used to keep updating those.    However, there are a few new feature that do require a re-image, and those were carefully noted in the release notes. If you don't need those features, then don't bother.


The main things that we do that require re-imaging are kernel upgrades.   Doing those via an upgrade script is "high risk" and have a good chance of making things un-recoverable, which would suck.  For the most part, those aren't needed very often.     

 

Back to top