search

allthingslinux / tux

Tux is an all in one bot for the All Things Linux discord server.
https://discord.gg/linux
GNU General Public License v3.0
85 stars 26 forks source link

Establish release guidelines and semantic versioning documentation #421

Open kzndotsh opened 3 months ago

kzndotsh commented 3 months ago

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

scottc943 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

but i also like electron idea

Anonymous4045 commented 3 months ago

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.

cherryblogsmedia commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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