It looks like we could do the branch switch fairly easily. Here is what I did:
1) Disabled main protection in .asf.yaml for main branch
2) Pushed fdbmain as branch off of main
3) Force pushed 3.x to replace main (since protection was removed)
4) Re-enabled protection for main and fdbmain
5) Replac
> I would like to suggest that we explore options with automation to try
to help remember all doc changes for a PR. I.e. the checkbox in the PR
template can help, but maybe we could also auto-label PRs with
"no-doc-changes" to remind reviewers, and/or have triggers for PRs
that do and don't touch f
Looking at https://docs.readthedocs.io/en/stable/versions.html, they
recognize an explicit "stable" tag or just picks the latest semantic
version branch or tag. They use https://peps.python.org/pep-0440/
rules to parse and that allows for a ".postN" suffix for a tag/branch.
So we could have a 3.2.2
+1, for the branch renaming part
For the docs integration part, I’m at ± 0:
Is it possible to distinguish what has been changed in a repository? For
example:
Are there changes in
- /docs -> rebuild and publish docs
- /src -> couchdb ci run
Or is it an all or nothing approach of PR’s in GitHub
I'm fully in favor of part 1, +1
On the docs, I'd say a slightly hesitant +1 as is, given the situation
Jan describes. I still think it would be an improvement to merge the
repo since PRs which correctly update couchdb+docs would more likely
keep changes and their docs together. Aside from direct
Heya Nick,
thanks for taking my raw idea to the larger group here :)
The one other point that started the whole thing is our publishing of docs.
We have a stable and a latest tag where latest just tracks the main branch
on the docs repo and stable we move manually when a new release comes out.
Good point about the CI, Jonathan. I think if we do this there might
be a way to skip the full CI if only docs changed.
As for historical reason, others would have to correct me here, but I
think there was a trend to split projects into smaller repositories,
one per Erlang application (roughly).
On 6/2/22 21:40, Nick Vatamaniuc wrote:
2. Move docs to the main repo.
We noticed that the docs repo tags/branches can get out-of-sync with
the main couchdb repo. We have been merging features in main when they
apply only to 3.2.x and it requires care to keep track of what gets
merged and porte
+1 on my side too.
Alessio
> Il giorno 2 giu 2022, alle ore 23:18, Robert Newson ha
> scritto:
>
> +1. It's time.
>
> B.
>
>> On 2 Jun 2022, at 20:40, Nick Vatamaniuc wrote:
>>
>> Hi everyone,
>>
>> In a #dev slack thread we were discussing improvements to how we tag
>> our documentation
+1. It's time.
B.
> On 2 Jun 2022, at 20:40, Nick Vatamaniuc wrote:
>
> Hi everyone,
>
> In a #dev slack thread we were discussing improvements to how we tag
> our documentation repo. There were two proposals to simplify the
> development and release process, and we wanted to see what the rest
Hi everyone,
In a #dev slack thread we were discussing improvements to how we tag
our documentation repo. There were two proposals to simplify the
development and release process, and we wanted to see what the rest of
the community thought about it. Those two ideas are:
1. Rename couchdb repo's m
11 matches
Mail list logo
