Pacstall v2.0 technically shouldn’t be 2.0

[Elsie19]

As we follow the SemVer style of versioning, 2.0 is the change from bash to python, but the goal is to keep all current Pacscripts compatible between bash and python. This would imply that no API was changed, and (assuming we did everything right) that no bugs were introduced, which would mean that this release should be 1.7, as it introduces new features, but doesn’t break the current API for pacscripts.

CC: @wizard-28

[wizard-28]

As we follow the SemVer style of versioning, 2.0 is the change from bash to python, but the goal is to keep all current Pacscripts compatible between bash and python. This would imply that no API was changed, and (assuming we did everything right) that no bugs were introduced, which would mean that this release should be 1.7, as it introduces new features, but doesn’t break the current API for pacscripts.

CC: @wizard-28

API was changed (UI makeover) but it's (we're trying) being kept backwards compatible.

Also we would sort of have to create these "wrapper" bash scripts which would wrap the python APIs. Enabling their use in the pacscripts, we still don't know how seamless these wrappers will be. So it's hard to tell if the API will break.

Also, it's better if we break the API. As we would be using the source array to get stuff downloaded from the internet (like PKGBUILDs) instead of url. Also we would make pacscripts as close to PKGBUILDs as possible. Just making them an upgrade (stuff like removescript, pkgver) over PKGBUILDs, but maintaining the core format. So adding in these changes whilst maintaining backwards compatibility would mean we would essentially have to parse and look for two different scripting styles instead of one. I think I should create an issue for this, as this was last discussed in Discord, and people may forget about it (looking at you).

Also I thought we didn't follow SemVer? As the releases start from V1.2 (also the SemVer website also states that putting in V or any letter in the release version is not SemVer).

So, in conclusion I propose that we simply call these release Kournikova in our development branches, as we still don't know how successful we would be in keeping the API backwards compatible. Again, I say we break the API's backwards compatibility, as this is a full blown rewrite I really don't want to maintain baggage from previous releases. I doubt the others would too.

[Elsie19]

Also I thought we didn't follow SemVer? As the releases start from V1.2 (also the SemVer website also states that putting in V or any letter in the release version is not SemVer).
The V is simply for fluff, not to be actually used

[Elsie19]

Ok, we can break the API, and the version will be 2.0.0