-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conventions for adding a new package to the build system #39
Comments
For item 1, does this (admittedly impossible to find) convention satisfy it? For item 2, I'm not sure I understand the question. Is it regarding packaging some upstream thing on a commit that is not an official release of that project, or something else? Is it possible to build the new version of |
I want to propose another alternative altogether! Why don't we just tag them as the version of software itself. Basically whatever is going to end up in The main reason is that for most of the packages we currently have, there is no difference in This practically removes the need for |
@khos2ow I'm not following your proposal. Could you provide a brief example?
There are really two processes we're talking about here:
In the existing Regolith build system, tags capture both of these. A lack of tag means a "floating" (AKA branch-based) |
I think I missed one aspect of the original question: branch names to hold Regolith-specific changes. This isn't covered in the script I linked above. I suggest we make the convention used in |
First of all, I'm still new to Regolith development so this might be totally off. But what I think is that release of Regolith (e.g. 3.2, alpha, beta or GA) is independent of versioning of the packages. For example, latest version of The reason is that Take the new archive structure for example and let's continue the same example for Where do we cut the tags from (i.e. original question here which I completely hijacked!) can be, as you suggested, be That means whenever there's a development being done in a package, we con follow the normal SDLC of it and cut a tag accordingly based on its development cycle version. And broadcast it here to be included in Voulage |
One quirk here ~ Any given release is a simplification of several (anonymous) releases. For example we say the current prod version of Regolith is 3.1. However, really we have several releases, one 3.1 release for Ubuntu Jammy, one for Debian Bookworm, etc.. But, we group all these under one "meta" release as a simplification. What happens in some cases is that for some given package, we need to build different versions of that package for a specific distro or a specific version of that distro. An example of this is There is a nuance to Debian version strings:
This works well for |
gtklock
has addedgtk-session-lock
as a dependency recently to support theext-session-lock
protocol that recently got stabilized and is supposed to really secure.For packaging this, I have created this fork and pushed the
debian/
stuff to thepackaging
branch. However, that branch tracks themaster
fromupstream
which is ahead of the latest stable release (v0.2.0) ofgtk-session-lock
.This brings up the following questions relating to the conventions for these cases (when adding new packages / forking is required).
master
branch (it would reduce the number of conflicts we need to deal with).HEAD
of the development branch (in this casemaster
) when forking.I think this closely ties in with the auto-tagging script created by Ken. Instead of polluting that script with yet another naming scheme when updating tags, I think I'll hold off adding
gtk-session-lock
to the voulage package model.@kgilmer @khos2ow
The text was updated successfully, but these errors were encountered: