+1 to fully automating the release pipeline. This would allow us to do as
many releases as needed to satisfy all stakeholders.
On Tue, Jan 12, 2021 at 4:11 PM David Davis wrote:
> There are some great features that have been added to Github Actions--one
> of them being manual triggers for
There are some great features that have been added to Github Actions--one
of them being manual triggers for workflows (before we weren't sure how we
could trigger the entire release process). So I think we're in a good
position now that we're on Github Actions to automate the rest of the
release
Stakeholder's won't agree on a single "LTS" (agreed daniel that's not a
great name for it) so I think option 3 is a non-starter. Option 2 is what
we do today and I agree it has the issues already mentioned.
So +1 to option 1, but as already mentioned, practically speaking, I
believe we can't
>
> Matt, that is a good observation and meanwhile with pulp2 we had such a
> policy, we cannot adopt it with pulp3. Release fast and release often is
> something we are trying to stick to.
>
I don't think Matt was suggesting in any way that we not release fast and
often, it's just that we have
I agree and I don't have a strong preference between option 1 and 3. If we
go with option 1 though, I'd recommend we prioritize automating the rest of
our release process. Otherwise, we're going to spend a lot of time
releasing.
David
On Wed, Jan 6, 2021 at 8:58 AM Ina Panova wrote:
> Matt,
Matt, that is a good observation and meanwhile with pulp2 we had such a
policy, we cannot adopt it with pulp3. Release fast and release often is
something we are trying to stick to.
It would be best to agree on the LTS version that would make all the
stakeholders happy but as it was pointed out
Another option is Current Version minus X (N-1, N-2, etc.) If for instance
you say we support N-1, and current version is 3.9, then you'll back port
to latest 3.8.x. N-2 at current version 3.9, would backport to 3.8.x,
3.7.x, etc. The advantages here are that you already set the expectation
for
Thanks for putting all the options together.
I would say that option 2 is a recipe for very bad user experience, and i'd
vote strongly against it.
I am ok with option 1, but I would add that the backport to the
intermediate minor releases _must_ be performed (as in released) counting
down, to
With more and further away backport requests coming in, there is more need
for a clear policy/docs to set expectations for users and to define
requirements for those performing a backport.
The question which hasn't been answered yet (in documented way) is:
*Should backports be backported to
