Remove release and codename properties from Compiler

[vrurg]

They're not relevant and are not used.

#2993

[timo]

should we have a deprecation cycle for this?

[vrurg]

should we have a deprecation cycle for this?

https://gist.github.com/Whateverable/9fa4650fecbba924da8ef4fa2580140d

I think if zef gets rid of it then we should be clear. I will produce a PR for that, just haven't got time yet.

[lizmat]

Technically, this should go through a deprecation cycle. Also, I'm not sure as to why these should be removed??

[vrurg]

Technically, this should go through a deprecation cycle. Also, I'm not sure as to why these should be removed??

Technically – yes, but does it worth the effort? With only zef referencing those and only to copy them over into another location?

The reason for removal is that both were used exactly once, in 2012 in 5d7626be and never more. With Raku/problem-solving#64 in mind I think it makes sense to get rid of useless remnants of an old experiment.

Anyway, no rush. The PR does no harm. Let it float around for as long as necessary to either merge or close. If deprecation is still considered reasonable in this case then I'll redo things.

[kawaii]

I would like codenames to remain personally. Or to put it more accurately - make a resurgence. Sadly I didn't get to help out much during the 2019.07 release but had I been in better health I would have made use of the codename feature.

[vrurg]

@kawaii How do you plan to use it?

[AlexDaniel]

Disadvantages:

• Having to decide which codename to use for each release = time wasted and unnecessary bikeshedding
• If there is one release every month (which is how it used to be), then that's 12 codenames per year, so nobody will ever remember which codename is which release
• The list of git tags is polluted with unnecessary terms if we decide to tag codenames too. For example, you can now do committable6: Bicycle say 42 and it will attempt to run it. There's no prebuilt version of Bicycle, unfortunately, because it is too old and whateverable doesn't go that far.
• Just as a principle, don't give nice names to things nobody cares about. Yes, people care about the newest release, but only until the next one comes.
• If you care, the idea of getting back codenames goes against my decluttering efforts, and in fact I want to get rid of language codenames too.

[kawaii]

@vrurg whilst I do agree with a lot of what @AlexDaniel just said I have the following stance: even if left unused - codenames are not doing any harm to the project. As I previously stated had I been in better health these last two weeks I would have made use of it myself. Nothing serious, just a sentimental little name or word with little to no meaning. I think it's nice for people who contribute to a project to be able to leave a part of themselves there with it - long after they might have departed.

[JJ]

Probably the best option here is to close the issue and carry it over to problem-solving. Would everyone involved, especially @vrurg , be OK with this?

[AlexDaniel]

Actually, I wish I was able to just merge this, but the PR for zef was never produced.

I think if zef gets rid of it then we should be clear. I will produce a PR for that, just haven't got time yet.

If we did change zef in 2019 then maybe we would've been OK-ish to just remove it now, but we didn't, so this will have to stay for now.