Potential backwards incompatible changes

[belak]

Well, I was hoping it wouldn't happen like this, but because there's no more base16-schemes-source repo (it seems to have been removed or deleted), backwards compatibility with previous builders is no longer possible.

If anyone has any backwards incompatible changes they feel like would be good to get in soon, let's discuss it here and see what we can do.

If possible I do think it would be best to still maintain compatibility with templates.

[belak]

One thing that came up before was https://github.com/base16-project/base16-schemes/issues/3. I'd argue that we should move those schemes into a folder called base16 (or schemes, but if we add other scheme "types" later, it would be helpful to have them in named folders).

[joshgoebel]

Some good news: if someone still has a local checkout (inside their builder folder, etc) the new builder versions should be able to work with that just fine (you may just need to move the folder) - the problem is that they can no longer be pulled down from the internet via the old URLS.

If we had any recent versions we could rename them ("legacy"), host them here release new older builders versions with the new urls? But I'm really not sure how many this effects and how hard switching to the new infrastructure really is (despite it being unintended).

Honestly I don't think the schemes switch (to the new unified repo) is that big of a bump but the loss of the older template list might be annoying for some in the short-term.

[joshgoebel]

into a folder called base16 (or schemes

I think perhaps if tools/builder are going to support a "folder of folders" that it should do so without the names mattering. I'd prefer "type" metadata (if needed) to be inside the YAML files themselves rather than based on the folder the YAML is stored in.

This would mean you could name it one thing now and another later and it shouldn't affect anyone.

[belak]

I think perhaps if tools/builder are going to support a "folder of folders" that it should do so without the names mattering. I'd prefer "type" metadata (if needed) to be inside the YAML files themselves rather than based on the folder the YAML is stored in.

My argument for separate folders is to keep the schemes separate: we've already got a ton of base16 schemes - if we added another "type" with a few schemes, it might be easy for them to get lost in the crowd of other schemes of a different type, especially because in the schemes repo they're not prefixed with base16.

[joshgoebel]

Oh, no argument on folders. I think we need multiple folders. I just don't think the folder should be what determines the type of scheme, ie the folder names should be for convenience only... builder shouldn't say:

• This folder is named "ansi16" so I'll treat it like a ansi16 theme.
• Rather the scheme.yaml should specify "type: ansi16" or some such.

IE, all data needed to build a scheme should live in its YAML file. It's place in any filesystem should be irrelevant.

[belak]

I'd be fine with that- maybe we could do both folders (for organization) and type: base16 (for building).

[joshgoebel]

Sure, though the folders could be added before the type field... type isn't needed until we actually hit the point of having two types. :-)

[belak]

This change has been made in the 0.11.0 spec