Don’t it hurt to abandon a project? ...unfinished LivePositioner project here.

@Simeon i’ve also got to point out that many of us might feel like it’s pointless to continue working in Codea right now if we know it’s all going to be flushed down the toilet in the next version.

@UberGoober I’m not throwing anyone under the bus and I’m not saying it won’t affect me. @Simeon asked what option we preferred. I preferred 2, you preferred 3. Will Simeon pick 2 because I preferred it, no. He’s going to do what he thinks is best for the continuation of Codea. If I have to convert projects because they don’t work in the newer version, I will or won’t depending if they’re important to me or not.

@Simeon Would there be a way to keep both versions of Codea. Have a latest version 3 that would no longer be updated, but can be loaded on the iPad, iPhone like normal along with version 4 that goes forward with updates. That way all the old projects can be run on version 3 or copied to version 4 and updated if required. There would be a Codea 3 app and a Codea 4 app. Codea 3 would no longer be updated but continue to work until it wouldn’t run anymore on newer iPads.

That would be similar to iLuaBox Pro that I still run on my iPad 1. It’s been dead on the App Store for many, many years, but as long as I don’t delete it from the iPad it’s still as good as it was on it’s last update.

@dave1707 that would be option (2). Keep Codea 3 on the App Store, and release Codea 4 as a new app. Codea 3 could continue to get bug fixes. Eventually, once everyone has migrated their code, Codea 3 can be removed from the store

@UberGoober the API will be largely the same so it certainly isn’t all being flushed down the toilet. It’s more about the immediate impact of upgrading — i.e., I don’t want to release an update to Codea that requires migration to all your existing code (even if they are minor changes) before you can run your projects. I don’t think option (2) would be bad for you: you can still load into Codea 3 to access and run your projects, and you can copy them into Codea 4 and migrate them at your own pace

So just to be clear under option (2) Codea 3.x would remain on the store, perhaps with a notice “Do not purchase this, it has been replaced by Codea 4”, have its icon changed to a “legacy” icon, but continue to receive bug fix updates for six months or more. And it could be run side-by-side with Codea 4

@Simeon I was thinking that Codea 3 could stay out there until it would no longer work on any iPad/iPhone because of hardware/software requirements. It would be accessible to anyone with Codea that wanted to still run Codea 3. It wouldn’t be updated after a certain point, but just left to die a natural death like other old apps. Hopefully by then everyone would be using Codea 4 and not miss Codea 3.

@Simeon I guess my suggestion (dual booting?) would be functionally very similar to option 2, I personally would just like having fewer apps to keep track of :slight_smile:

@Simeon thanks outlining the possible ways forward. Option 2 makes sense in terms of an application but will probably have the biggest impact in terms of this forum as a resource with the wealth of examples which have been built over many years. There will be the current active user base who will likely embrace the transition but the entry point for new users (in terms of support and examples) will need thought. Will Codea 4 still be called Codea? Who is your market for version 4? What will the "typical” Codea user look like and want to get out of Codea?

@West - good points about the transition. But hopefully the current support will be busy transferring code and new users will be able to pick up on it. Most of the old code won’t work directly but forum members would be there to plug the gap. Also we need a WebRepo for anything transferred that authors are willing to donate to the rest of the members. May go quiet for a while whilst regular users catch up and learn about 4.

@dave1707 the only problem I have leaving Codea 3 on the App Store is that I don’t want people to accidentally purchase it when Codea 4 is available. Perhaps it can be removed from sale but still made available to those who want to re-download it from their purchases list

@West I am not sure what a typical Codea user looks like, we have just been building it because we like it

It will be similar enough that it will still be called Codea. Good point about the forums, perhaps we will use the update to transition to a new discussion platform — something with much better spam prevention hopefully

@Simeon Thats kind of what I had in mind. Codea 3 wouldn’t be for sale, but still available to Codea 4 users. Like on TestFlight where we can download previous versions of Codea but be able to have both Codea 3 and Codea 4 on an iPad/iPhone.

While option 3) is more effort I think it’s the right path to take. It would simplify a few things for you regarding trying to maintain multiple Apps, and provide the support that every one who uses Codea would need.

@skar @Simeon There wouldn’t be multiple apps to maintain. Once Codea 4 is available, that would be the end of updates for Codea 3. It would be there for Codea 4 users to use as is, but without anymore updates.

@skar I guess the biggest problem I have with (3) is that we would be shipping tens (or hundreds?) of thousands of lines of code more than we need to. We would also have to maintain a legacy project format, a different UI for loading legacy projects that locks out new features, and ability to migrate a legacy project to a new project

We kind of get all that “for free” by keeping Codea 3 on the App Store, where you can migrate your project when you’re ready by dragging it into Codea 4 in the Files app and working on it from there, while keeping Codea 4 slimmer and more focused

Personally, I like (1) and (2) the most. From what I’ve seen, the update is by far the biggest Codea has recevied as of yet, so I feel it’s a fair choice to release Codea 4 as a new app. I’m quite worried about how much of the compatibility will be broken, though, as my project relies heavily on mesh and shaders. From that standpoint alone, I think it would be good to have two separate spaces.

However, providing wrappers e.g. for mesh would really really help and make the transition smoother. Otherwise, migrating larger projects will be needlessly difficult/frustrating. Especially if you are short of time, it’s frustrating to rewrite code that already used to work.

@Elias yes I think we would be providing wrappers for legacy Codea functionality. Something like a legacy module where you can redefine mesh by using

mesh = legacy.mesh

Or something like that. These would be written in Lua and we could make the code editable and part of Codea 4

Hopefully no one minds if I refer back to OT for a moment: would anybody be interested in me finishing this?

It was heartening to see @Simeon write that it seemed useful.

Right now I’m just chopping up the pieces and posting them as individual tools (it’s improving the code a lot actually).