Yes, moving towards PEP8 compliance has been a long time aspiration and we had to bite the bullet at some point. We tried several times in the past but if you don’t do it and publish quickly then you have problems with other developments (as you experienced). Indeed, we have several devices branches that will need to be similarly merged. It’s a headache.
1 Like
Just curious, have you ever considered adapting semantic versioning and using Gitflow or trunk based development?
No. We never considered this “semantic versioning” and we don’t plan to do it in the short term.
Regarding “gitflow”, we are not far from it. Indeed, we could say that we currently follow the main guidelines from gitflow and our current version tree is quite similar to this one:
where our current “develop” branch is called “vangelis” and our current “release branch” (staging) is called “oram”, where we set the “stable” tags. We don’t have a separated “master” branch for the stable “tags”. We tag directly in the staging branch.
Regards,
1 Like
That’s why I asked 
you seem to have a strong opinion against semantic versioning, considering that it is almost industry standard by now, is there a special reason?
I’m not against it, but IMHO, it doesn’t fit our development model and it’s “too bureaucratic”.
ZynthianOS is composed of many packages, with the zynthian specific software on top of them.
This zynthian specific software is splitted in several repositories:
- zynthian-ui
- zyncoder
- zynthian-webconf
- zynthian-sys
- zynthian-data
these repositories evolve separately, but there are dependencies between them. Having a “common semantic version” for all of them have no sense and having a “specific semantic version” for each would be hard to maintain. It would make things more complex and i doubt the benefit is worth the effort.
We have found a kind of “zen” with our current “kind of gitflow” with lovely “branch names” and we would like to keep things like this for a while, so we can evaluate if this fits our development model.
Regards,
4 Likes
Well, we fail with the first requirement of semantic versioning:
We aspire to this but are not there yet. I have tended to use semantic versioning for the past few decades for most of the libraries and applications that I have written and in some ways you can consider zynthian to do similar in that it has a major release (Oram 2409) and a minor (.1) although the minor and patch are the same - which is not uncommon for OS. zynthian is not a single library or application. It is a whole operating system. Look at how Ubuntu use major/point release or Mac and Windows use similar.
As @jofemodo describes, we don’t want the administrative overhead of managing lots of versioning. Each module, the whole system, etc. So we are trying this approach and seeing how it goes. The problems experienced recently are not due to the versioning system but instead, due to the implementation. As long as the developers and users can uniquely identify the state of a system (fairly simply) then we are achieving our goal and the simpler it is for everyone, the better. Now where did I put my riban version 1234.5678.90000?
2 Likes