Closed felixfung closed 1 year ago
Actually perhaps 0.9.0?
The rest of the issues would be 1.0.0, or 1.1.0 for the cosmetic issues.
well you have to think of what will happen then outside of your own individual control....
with a 1.0 it becomes assumed that you are willing to let users some assumptions of long term support: but myself i am not (and actually cannot). so there is definately a value in staying away from ever reaching 1.0, because it prevents this from ever becoming an assumption. take pipewire project as an example. it is 0.38 and this is precisely the reason. to not give a misrepresentation in terms of bugs, crashes and corner cases. in terms of skippy that might translate to the fact that everybody is on different de's / window managers. which can behave subtly different. to you want users to over assume support for all their random wms? --> probably not
but you should also not just think of the user expectations, but of distros too, that whether or not to spend their own time / effort keeping and maintaining as an official core pkg. most distros actually have well defined policy guidelines for those sets of criteria. it is worth becoming familiar to know their expectations, the implications. since it is often good to play nice. especially if you want distros to pick up the pkg for a wider circulation / wider userbase availability.
from a functional perspective of git. for all of use actually building from git:
then tagging at a more regular checkpoint level whenever you feel the code is runnable and not buggy or crashy... that is what i look for as being far more useful.
(instead of a formal released version). and this also goes a long way to help distros decipher the meaning of the actual version number. to better take from git and update when they assess it is an opportune time. during a window that the code has lingered in a good state. and not feel obliged to update for example to ping them 1.0 that then you know full well is incomplete. or ships with bugs etc, that has to then be updated so soon again etc. because it genuinely was too early to pull that trigger.
you also need to wait for me. to take some look and give some feedback. (which is still pending but should be fairly soon).
Oh I see. Thank you for the explanation. I had no idea at all.
When you are ready I still think we are ready for 0.7.0, together with git tag, since we have changed the command line parameters and also made substantial improvements and bug fixes.
we absolutely will need to make as a new version! - just please allow me to come back with my assessment for those review the current state.
whether to wait for me before incrementing to the 0.7 and then make some 0.7.x patch update i don't mind at all.
Thanks for merging.
I have created new git tag v2023.06.25, after merging #144, a very important feature for user experience I have been trying to implement for a long time.
@dreamcat4 I think there is substantial change since 0.6.0?