Closed Protonull closed 2 years ago
Why not just add back in the maven profiles, so you only build latest by default and can get the old ones using profile "all" ? That's how it used to be, not sure when it was changed. Then you don't need anything but latest paper.
Because backwards compatibility is about to be royally screwed since NameLayer sets a player's civ-name (the name they keep even if they change their Minecraft account name on Mojang's site) via reflection of final fields, something that Java 16 now disallows.
I'd also hazard a guess that even if you tried to compile NameLayer with an older version, it wouldn't work by nature of CivModCore making no effort to support separate versions, and also being compiled with Java 11, which iirc 1.12.2 and below don't like.
Supporting older versions either means restricting ourselves of Java 16's feature set; or having to update every older version's code anyway to run on higher JVM versions (like having a 1.13 server on Java 14 or whatever); or generating a multi-release jar, which iirc is a Java 9+ feature so wouldn't matter for 1.12.2 or below anyway.
so then why is this a question? If the marks against are so absolute, it doesn't even bear discussing.
Weeell, firstly because it's not impossible to support older versions, just a lot of work, like by splitting it into pre-java9 and post-java9 modules, plus removing the dependence on CivModCore (or doing the same to CMC), etc. And so decisions like this should at least be discussed, if only because then it's on the record as not being an arbitrary decision by a single developer which hot-heads can point the finger at.
That'd never happen! ;P
No, I understand why. There's a grand tradition of checkpointing versions, then making non-reversible moves into a new release while abandoning support for prior releases.
I think unless some other greybeard hothead chips in, you'd be fine to do the same to Namelayer. It'd suck as it's been one of the coolest things about it -- but the kind of tech debt that's accruing makes it seem quite pointless at this point.
Perhaps I'd feel different if I was the one doing the upgrade, as I'd personally preserve the back-compatibility just b/c that's what's already there, but I wouldn't want to saddle you personally with that task, especially if you didn't desire to do it.
On Tue, Jun 1, 2021 at 4:50 AM Alexander @.***> wrote:
Weeell, firstly because it's not impossible to support older versions, just a lot of work, like by splitting it into pre-java9 and post-java9 modules, plus removing the dependence on CivModCore (or doing the same to CMC), etc. And so decisions like this should at least be discussed, if only because then it's on the record as not being an arbitrary decision by a single developer which hot-heads can point the finger at.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CivClassic/NameLayer/issues/39#issuecomment-851951231, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADD5DQXTPD4ZYEVB3PBUBTTQSNN5ANCNFSM45ZG3ZUQ .
NameLayer has attempted to keep backwards compatibility by having a number of internal packages that solve the question of storing each player's civ-name within NMS itself for as many versions as possible. The problem is however that because each version relies on NMS means that anyone wishing to develop NameLayer needs to locally install all of those Spigot and Paper server versions. We've mitigated this somewhat by only linking the current version, so in a sense we've already done this, except that the project is now littered with old code that's never used. DevotedMC's NameLayer has already done this and moved away from per-versioning, as it were. This issue is about whether we should do the same, and not even just for NameLayer.. the same issue exists with, for example: CombatTagPlus.