Release and versioning guidelines

[kzndotsh]

This issue is to discuss our plans for release structuring and version numbering.

[scottc943]

https://semver.org - we could just do a minor version per PR by default unless it is prepended by like [FIX] then do a patch. For major versions it's hardly going to "happen", but if we make a big change that doesn't work in version 1.X.X then we should go to a next version similar to an api.

Are features breaking changes? Some could argue for it. Features added in X.1.0 won't be the same as 1.0.0 therefore tux 1.0 could not run the "jail" command but tux 2.0 would

Maybe features are the major version change here

[electron271]

x.y.z
x - breaking changes which require hosters to do large changes to their infrastructure (e.g migrating platforms)
y - changes that may require some configuration on the hosters part
z - changes that require little to no changes on the hosters part

[kzndotsh]

x.y.z

x - breaking changes which require hosters to do large changes to their infrastructure (e.g migrating platforms)

y - changes that may require some configuration on the hosters part

z - changes that require little to no changes on the hosters part

Do our releases only take into consideration self hosters and contributors? What about server owners that adopt our main bot if we ever go public? e.g. we change all the arguments for a command group.

[Atmois]

i think we should do x.y.z and have a list of guidelines what counts as x and y and everything else is z

[Atmois]

but i also like electron idea

[Anonymous4045]

I think first we should figure out who these versions are primarily for. If it's for the people hosting and doing dev work on the bot, then electron's idea makes the most sense. If it's for community members following changes in the bot, it might look different. One idea:
x.y.z
x: User-experience redesign. This could be a change affecting most users of the bot, so the members would need to relearn commands. We should avoid this, but it does happen as discord itself and the community evolves.
y: A new feature that the users can learn, or a notable change in how a command works.
z: Refactoring, bug fixes, optimizations, etc. that don't affect the user.

[malcontent5]

I think first we should figure out who these versions are primarily for. If it's for the people hosting and doing dev work on the bot, then electron's idea makes the most sense. If it's for community members following changes in the bot, it might look different. One idea: x.y.z x: User-experience redesign. This could be a change affecting most users of the bot, so the members would need to relearn commands. We should avoid this, but it does happen as discord itself and the community evolves. y: A new feature that the users can learn, or a notable change in how a command works. z: Refactoring, bug fixes, optimizations, etc. that don't affect the user.

second this i like this idea

[kzndotsh]

I'm still not 100% sure on the versioning specifics so I will do some thinking/research but I do imagine we should probably have two types of change logs, one for server usage and one for developers. Maybe it could be one change log just organized in two parts or something per new post.

[electron271]

I think first we should figure out who these versions are primarily for. If it's for the people hosting and doing dev work on the bot, then electron's idea makes the most sense. If it's for community members following changes in the bot, it might look different. One idea: x.y.z x: User-experience redesign. This could be a change affecting most users of the bot, so the members would need to relearn commands. We should avoid this, but it does happen as discord itself and the community evolves. y: A new feature that the users can learn, or a notable change in how a command works. z: Refactoring, bug fixes, optimizations, etc. that don't affect the user.

i think it should be primarily for self hosters, if self hosters have a issue the whole bot will go down on update, if its just a command argument change its just a bit of relearning, no big deal

[h5law]

Typically semver [1] x.y.z correlates to

x -> interface/api/logic changes that introduce a break in backwards compatability (potentially)

y -> minor upgrade that doesn't affect backwards compatability but improves/changes/etc some aspect of the codebase

z -> patch that affects nothing - docs/small bug fixes (big ones or long standing ones that may be considered a feature to some should be in y or x respectively)/tests/etc

IMO the versioning shouldn't target self hosters or whoever else but instead just follow this pattern. Then it will be clear to anyone using it if we go from 1.2.3 -> 2.0.0 they may need to change their code/integrations/etc but 1.2.3 -> 1.2.4 or 1.3.0 they can get away without changing while still upgrading - but may not utilise new features etc

[1] https://semver.org/

[electron271]

discord bots cannot use other bots commands, the most that would happen if arguments are changed is a bit of annoyance, the most that would happen if self hosting stuff is changed is longer downtime

[electron271]

if we add like a web api for like a web panel though id agree with using exact semver