lanefu Posted October 11, 2019 Posted October 11, 2019 Quote New naming convention is getting to its final stage of development. Beside name I also RFC packaging patch which had hard coded dev/next values inside so it was a must to deal with. Since we have new package naming and we will need to create some upgrade automatism in any case ... shell we change to more logical/proper versioning too? We had debate over but can't find it. Was it on Github? @lanefu New thread for that? There's been discussion in the past of switching to a YY.MM naming convention for releases (similar to Ubuntu) [citation needed -- I think it may be buried deep inside a github discussion] How does that impact us as a rolling release? What do we want to convey with our versions/releases? Should we do monthly releases? quarterly? I do think time-based releases would help us with priority.
Igor Posted October 13, 2019 Posted October 13, 2019 On 10/11/2019 at 2:02 AM, lanefu said: How does that impact us as a rolling release? Since we are low on resources, we probably can't afford to provide LTS and rolling. But we can preset some numbers for the future and label LTS certain builds if there will be a dedicated support team for that. Just simply sync to either U-boot or Ubuntu ... 5.98 -> 19.10.1
chwe Posted October 14, 2019 Posted October 14, 2019 if we have the same naming as ubuntu, people expect the same behavior (e.g. 20.04 being then a LTS version). I would consider being part of LTS on one kernel as long as we have a proper definition such a LTS "project" (e.g. features don't get back-ported, running boards more conservative to keep the maintenance coast lower). Without clear 'rules' what people can expect from a LTS-like build and what they can not, it doesn't make sense.
Igor Posted October 14, 2019 Posted October 14, 2019 3 hours ago, chwe said: people expect the same behavior Yes. Then its better to stay on generic versioning since Armbian is already not exactly the same as Ubuntu. We put a kernel in the centre and attach userland on that. Also add Debian's. This default/next/dev or legacy/current/dev already tells a lot about support status and since kernel is the thing we have now LTS around 4.19 ... which is good for most, while Allwinner is better to upgrade to 5.3.y and ASAP to 5.4.y when its out ... To not confuse with Ubuntu, we have probably only one option left -> 2019.10.n ... next major version 2020.02.n ... n for bug fix releases. Is this clear enough? It is unrealistic to properly maintain an LTS version at this stage. When we agree on this, branches shell follow this naming - clean out older. Master have version 2019.10.n, development (arm64 at this point) becomes 2020.02 or whatever its appropriate. Goal is that its clear at once where things are getting developed. - branches shell not go too far apart. Merging must be possible all the time. - critical fixes goes to both branches - other branches are open temporally only for features development - if any of those processes can be automatised, task should be put to Jira and version tags shell be set for the future in Jira. Clear rules, protocol of changing and communicating to the users ... and clearing possible points of confusions anywhere possible.. 4 hours ago, chwe said: I would consider being part of LTS on one kernel Can we define into the last detail, what would that represent? If someone knows exactly what shell be done, its easy and I am sure more people will be able to help. If we focus to master (2019.10) and development (2020.02) and if I focus only on development, someone should take care of current master branch. Merge bug fixes, while leave features for 2020.02. They need to be well tested. beta.armbian.com is ofc attached to 2020.02. One of the must-do tasks for the maintainer of this branch: In case a pull request with the fix or feature comes to the master (2019.10) it has to be shared upstream, to development as well. Also one should pull critical things from the development without any special request.
Tido Posted October 14, 2019 Posted October 14, 2019 16 hours ago, Igor said: we probably can't afford to provide LTS and rolling 2 hours ago, Igor said: When we agree on this, branches shell follow this naming did you now find a way to do it anyway, with as little people as armbian is?
Igor Posted October 14, 2019 Posted October 14, 2019 34 minutes ago, Tido said: did you now find a way to do it anyway, with as little people as armbian is? This will only properly label the existing work done mainly by me in various branches. I started to develop some new feature, but perhaps more has to be fixed and rather make move to a new release. So "arm64", where most of the work and where naming is totally derailed from the actual work shell be renamed to new branch ... its an attempt to make it easy for others to join. If they have an interest, otherwise this will remain just my upgrade. But until nobody knows this is actually an upgrade, not just fixing one function, nobody even look into until its done. You can see what was already fixed, there are pleads what its nice to fix and perhaps some other have an idea to squeeze in some feature. Ideally this process shell be planned within Jira. This is not maintaining a separate LTS branch. 1
Igor Posted November 5, 2019 Posted November 5, 2019 WIP: Release Modelhttps://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md
Recommended Posts