Replies: 1 comment
-
Thanks @RachL ! I agree this is definitely cross topic with Ontology team (although we're mostly here already 😉): ping @Alcoz ! I guess I was thinking of a monthly release schedule: e.g. we release on the 2nd Tuesday of each month. I think I'd like to have a few other constraints, for example: we won't have a major release more than once or twice a year; i.e. at least 12 months since the last (or penultimate) major version was released. This has a couple of advantages: we ensure the team doesn't commit to too much work & if we are committing to support 2 major versions of the the standard, we ensure stabilise the standard for developers, so they can work with it, knowing breaking changes won't be appearing every month. So I guess I have a few questions for the team:
|
Beta Was this translation helpful? Give feedback.
-
Following this slack discussion, here is my feedback to start the discussion.
At the OFN we have a regular release procedure (every Monday a new release is published).
This has several advantages:
The team does not have endless debate on whether now is the good time or tomorrow // which issue to include or not: time becomes the constraint. Some literature are using the image of a train: if one PR misses the train, it can take the next one.
Instance maintainers have a clear schedule and know when to expect new things
So on my side I don't think I can give an opinion on the frequency of the releases (aside of NOT releasing weekly 😁 ) but I'm in favor of a regular schedule we can communicate / plan on. This means releases can vary in size, but that should not be a problem.
Any thoughts?
pinging the tech working group @simonLouvet @RaggedStaff @jgaehring @lecoqlibre
but maybe this is a cross topic with ontology maintainers?
Beta Was this translation helpful? Give feedback.
All reactions