Find a solution for identifying future platforms

[theseion]

Possibilities:

• FLFuturePlatform class
• dedicated test case
• auto generate new platform class
• ?

Unfortunately, the current architecture relies on Metacello providing the platform identifiers and Metacello has the same problem.
In addition, even if we introduced something like an FLFuturePlatform class, it will at some point be necessary to create a new class specific to that platform, at the latest when the next platform version is up.

[astares]

see #227

[marianopeck]

Hi @theseion

Thanks for taking care of this. To me the easiest looks like a test case that acts as a reminder for us to create the class. As soon as a new Pharo release comes up, this test fill fail. Then we create the class and we are done.

[theseion]

This also requires removing the previous platform class in case of Pharo, as it's part of the core sources and will not automagically disappear (Fuel is not being loaded through the configuration / baseline).

[astares]

Usually we do not remove classes directly. We move them into Deprecated70 package so they will be still shipped (to stay compatible for a white and tell people not to use them anymore).

So when a new Pharo 8 start we then delete the Deprecated70 package and they are gone

[theseion]

I understand but the platform classes are not public. They are Fuel internals.

[astares]

OK. Fine!

[tinchodias]

Ah, doesn't Pharo 7 load Fuel via ConfigurationOfFuel?

A test seems enough, at least already an improvement.

[theseion]

No. Fuel is part of the pharo-project/pharo source.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will remain open but will probably not come into focus. If you still think this should receive some attention, leave a comment. Thank you for your contributions.