Re: [DISCUSSION] Allowing commits to a released branch for documentation purposes
Hi Peter, Thanks for reminding the nuances. It's been a while since I contributed to the codebase. Ok, then I think nobody will object that the docs will always be published from a release branch such as ignite-2.9.1 and then we can commit to the branch directly if 2.9.1 needs to be updated. Wrote this down in the docs contribution process: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document#HowtoDocument-PublishingtotheWebsite - Denis On Mon, Dec 21, 2020 at 10:40 PM Petr Ivanov wrote: > Hi, Denis. > > > Apache Ignite as other projects on Apache is in fact released from TAG, > not BRANCH (although they are similar at that point). > Thus — it seems that there should be no problem to continue using branch > as docs sources for the same release as long as TAG stays intact. > > We just have to document the process as it is, so there are no questions > about why the branch moved forward after release. > And possibly add some checks (on TC, for instance), that the changes in > released branches are only about documentation, and do not touch other part > of the project. > > > > > On 22 Dec 2020, at 00:47, Denis Magda wrote: > > > > Igniters, > > > > After we release a version, we create a docs-specific branch out of the > > release branch for inevitable documentation improvements (feedback; > generic > > changes that are committed to the master, and the last published > version). > > For instance, once 2.9 was released from the "ignite-2.9" branch, we > > created the "ignite-2.9-docs" branch whose content is published on the > > website (https://ignite.apache.org/docs/2.9.0/). The only reason why > > "ignite-2.9-docs" is created is to follow an internally defined process > > that prohibits commits to an already released branch such as > "ignite-2.9". > > > > Can we remove this restriction, at least for documentation changes? We're > > approaching the 2.9.1 release. The 2.9.1 docs will be published from the > > "ignite-2.9.1" branch as the rest of the release artifacts. Then, over > > time, we'll be improving the pages and need to publish changes for ignite > > 2.9.1 on the website (until it stays the latest released version). We'd > > like to cherry-pick those changes to "ignite-2.9.1" and not to create > > another branch such as "ignite-2.9.1-docs" for that. > > > > > > - > > Denis > >
Re: [DISCUSSION] Allowing commits to a released branch for documentation purposes
Hi, Denis. Apache Ignite as other projects on Apache is in fact released from TAG, not BRANCH (although they are similar at that point). Thus — it seems that there should be no problem to continue using branch as docs sources for the same release as long as TAG stays intact. We just have to document the process as it is, so there are no questions about why the branch moved forward after release. And possibly add some checks (on TC, for instance), that the changes in released branches are only about documentation, and do not touch other part of the project. > On 22 Dec 2020, at 00:47, Denis Magda wrote: > > Igniters, > > After we release a version, we create a docs-specific branch out of the > release branch for inevitable documentation improvements (feedback; generic > changes that are committed to the master, and the last published version). > For instance, once 2.9 was released from the "ignite-2.9" branch, we > created the "ignite-2.9-docs" branch whose content is published on the > website (https://ignite.apache.org/docs/2.9.0/). The only reason why > "ignite-2.9-docs" is created is to follow an internally defined process > that prohibits commits to an already released branch such as "ignite-2.9". > > Can we remove this restriction, at least for documentation changes? We're > approaching the 2.9.1 release. The 2.9.1 docs will be published from the > "ignite-2.9.1" branch as the rest of the release artifacts. Then, over > time, we'll be improving the pages and need to publish changes for ignite > 2.9.1 on the website (until it stays the latest released version). We'd > like to cherry-pick those changes to "ignite-2.9.1" and not to create > another branch such as "ignite-2.9.1-docs" for that. > > > - > Denis
[DISCUSSION] Allowing commits to a released branch for documentation purposes
Igniters, After we release a version, we create a docs-specific branch out of the release branch for inevitable documentation improvements (feedback; generic changes that are committed to the master, and the last published version). For instance, once 2.9 was released from the "ignite-2.9" branch, we created the "ignite-2.9-docs" branch whose content is published on the website (https://ignite.apache.org/docs/2.9.0/). The only reason why "ignite-2.9-docs" is created is to follow an internally defined process that prohibits commits to an already released branch such as "ignite-2.9". Can we remove this restriction, at least for documentation changes? We're approaching the 2.9.1 release. The 2.9.1 docs will be published from the "ignite-2.9.1" branch as the rest of the release artifacts. Then, over time, we'll be improving the pages and need to publish changes for ignite 2.9.1 on the website (until it stays the latest released version). We'd like to cherry-pick those changes to "ignite-2.9.1" and not to create another branch such as "ignite-2.9.1-docs" for that. - Denis
