Releases and development cycle #852
dmlloyd
started this conversation in
Design discussions
Replies: 1 comment
-
For people like me who might cut & paste commands from a discussion without thinking enough 🤦♂️ |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Now that the initial tags for the project have been released (0.1.0 for Qbicc and 11.alpha.0.1 for the class libraries), things are changing a little bit in terms of how the development cycle must work.
On the upside, not having to rebuild the class libraries speeds up CI a bit. Also, we should not see the Maven resolver warnings at the beginning of compilation (with a corresponding speed improvement) as long as the release version of the class libraries are used. But on the downside, it is somewhat more complicated to develop features and fixes which rely on both Qbicc and the class libraries to be updated.
First, the easy part. In order to use a locally-built version of the class libraries, give
--rt-version=11.alpha.0.2-SNAPSHOT
as an argument to Qbicc (this has a bug; see #851 for the fix). To rebuild the class libraries against a locally-built version of Qbicc, give the following argument to Maven:-Dversion.qbicc=0.2.0-SNAPSHOT
(or, editpom.xml
locally to refer to the snapshot version if you need your IDE to recognize these classes).Now the hard part. It is fairly difficult to perform a lock-step release of these two projects. This means that we need to be mindful of what we're developing, such that we follow these principles:
This might mean that things need to be deprecated and then separately removed, for example, or in the worst case, that a temporary workaround be put in place which we then remove after the opposite artifact is released.
The good news is that releases seem to propagate to Maven Central within an hour (it takes longer for it to be indexed on
search.maven.org
but that's OK), so it should be possible for me to perform releases of the individual projects pretty frequently (at least to start with). I'd like to get to a point where we have some kind of cadence, like releasing Qbicc mid-week and releasing the class libraries at end-of-week, eventually slowing down to biweekly or even monthly tags, but for now we can stick to survival mode and do things ad-hoc until we're all sure that this is a feasible approach.Beta Was this translation helpful? Give feedback.
All reactions