-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version-specific cantera.org release cycle #150
Comments
We used to have the website built entirely from content stored in the I took a look at the PRs that have been merged to the website repository since we released version 2.5.1, and found the following.
So I think the current organization of having the default branch (which is the default target for PRs) be the branch that generate sthe main For documenting new features, I think having information available on You're right that there will be a substantial update to the documentation related to the removal of the CTI/XML formats. However, I think the only way to do this without creating a maintenance burden is to wait to do that until we're close enough to the 3.0 release that we actually want to start maintaining a branch for updates that should go live only with the code release. The earlier we start such a branch, the more likely it is that we won't be able to merge/cherry-pick some of the more common version-independent changes. I appreciate the thinking on this issue. Clearly, whatever we decide to do, just documenting the workflow and keeping it in mind when we're preparing and reviewing PRs will be an improvement over the current ad hoc process. |
@speth ... thank you for the historical context - this is certainly something that I appreciate. Also, thank you for dissecting website updates between 2.5.1 and 2.6. At the same time, the points I brought up were based on my experiences and observations during this release cycle, which left me wondering whether the work flow couldn't be improved. Separate repositories: I think that is generally the right call. The current structure is error-prone. Take for example recent changes to Science (Cantera/cantera-website#179), which broke section links that were inadvertently (and independently) discovered and fixed in Cantera/cantera#1249. Links to new features in the dev version are awkward (see issues with broken links in I don't think that stats on PR's to the current website are entirely meaningful as they are a function of the current work flow. The review cycle isn't smooth: updates are (by necessity) deferred until a later point, and reviews are likewise not a priority. The ensuing lags between preparation/review of features and the necessary documentation is frustrating, and may lead to less-than-ideal results. It's imho better to write documentation when memory of a feature is fresh, and having results appear on
This is a somewhat scary prospect and was part of the motivation for putting this enhancement request together. Please note that my suggestion avoids merge/cherry-pick altogether, as source code for Overall, from my side the positive aspects of updating the work flow as outlined at the top of this issue report outweigh the status quo. Ultimately, it is my interest to make for a smoother experience: the hurdle before a release appears to be unnecessarily large. |
I'm going to reply to a few specific quotes first and in the next comment consider the actual proposal from the OP and how we might move forward.
As just a tiny bit more historical context, we avoid links to That said, on a separate but related note (as you suggested in the OP), we should probably do a better job of
I disagree with this position. I think that since we only release once-a-year (and until the last three releases, somewhat less frequently), it's important to have this documentation publicly available for people who want to use features only on the
I definitely agree that there is a good possibility of errors with links 😄 However, I would argue that the specific cases you mentioned here would have happened even if the entire website was hosted from the
I agree we can do a better job with timely reviews; it's basically a bandwidth and interest issue (writing new features in Cantera/cantera is more fun, etc.). I think we can also require docs for new features here before merging PRs in Cantera/cantera; this is a loose requirement that we haven't always enforced but which we could do going forward. This means we could make new docs available on
Regarding the removal of CTI/XML, YAML has been available for a while now and seems quite stable. In the docs hosted in |
Ok, to address the actual proposal for changes here:
I think this kind of structure would work better once we actually have complete documentation for more of the features in the As such, I anticipate that the majority of the updates that we'll make until we have more complete documentation are changes that would be relevant to the current release. For example, I'm thinking of adding Peng-Robinson documentation, or lifting things out of the C++ docstrings to the "Science" section. As these would apply to the stable version, we'd end up having to backport it from As far as improvements to the process, I think the hardest thing (aside from cross links) that we have to do at release time is make sure that the api-docs are updated (@speth please correct me if that's wrong, since you did all the stuff for this release). With how this repository is currently structured, I'm not sure how to improve this step... but I can imagine that we can rearrange this repository to make things better. I'll consider that and try to come up with a concrete proposal. To fix the cross links, I'm considering switching the website back to Sphinx. It seems like combining Sphinx-generated sites will be easier than mixing generators, and I'd like to be able to use MyST Markdown, which is easy to add to Sphinx. This will also allow us to delete several of the plugins I wrote for the Nikola site that accomplish features which are built-in to Sphinx. As @speth said, thanks for starting this discussion @ischoegl. I think it's important that we make some improvements here. So, items that I'm taking away from the discussion so far:
|
@speth and @bryanwweber ... thank you both for your thoughts. I think the discussion was fruitful, even if my original suggestion may not have support. I know that there have been long-standing goals to improve the documentation (#6, dating back to 2019, although duplication was pointed out in Cantera/cantera-website#20 and efforts to catalog and verify classes go back to at least Cantera/cantera#267). Cantera/cantera-website#146 is a small initial step, so I hope that this will pick up some - arguably the science documents qualify as "reusable and open educational materials". I am personally not too unhappy with the Nikola approach (it works), but can see that writing documentation could be easier / more approachable in MyST markdown. Going back to Sphinx (or even further to jupyter-book, which is just 'opinionated Sphinx') is likely a major effort; I am not keen on volunteering myself, so I don't want to force that on anyone. The one thing I am hoping for is to be more proactive on the website: documentation of new features should be more consistently posted immediately and appropriately marked (new in Cantera X.Y), perhaps with the exception of experimental features. Likewise, we should consistently mark deprecated code immediately (removed after Cantera X.Y) - as is currently already done for CTI/XML. Transitions between versions will be arguably harder to administer, but there appears to be broad support for this work flow. One thing that we could perhaps improve in the API docs is the formatting for the 'deprecated' admonition, and to potentially define a 'new in' admonition for features that are added in the development version. That way, there may be a way to always link to the most current API docs as they would cover both the latest stable version as well as the upcoming development version. This would also avoid the PS: Also linking #115. |
The bigger thing to me is being able to delete the plugin code
I agree, but I don't think this was a huge problem for this release. Are there examples you can think of, aside from Peng-Robinson?
Agreed, this would be nice |
On the On a separate, - albeit related, - note: I just discovered another broken link 😜 If we find consensus for admonitions, this should be relatively easy ... especially if we figure out a way to link to the current API docs, it would be a huge step forward. Based on where this discussion is going, it would be great if we could eliminate |
Update: I looked over the Sphinx documentation this morning, and suitable directives already exist (which is not entirely surprising): .. versionadded:: 2.6
The *spam* parameter. and .. versionchanged:: 2.6
The *eggs* parameter. We are obviously already consistently using .. deprecated:: 3.0
Use :func:`spam` instead. Fwiw, the I tested the From my perspective, a consistent usage of these features would be useful in general, and potentially even allow us to link to the current API docs (rather than stable API docs), as everything is appropriately marked. |
Doxygen also apparently has the |
@speth ... I really like the Fwiw, I added some instances of |
@speth / @bryanwweber .... Ok. After running some tests, I believe the following modified workflow would be workable: New Features: Use Changing Features: Mark feature as Deprecated/removed Features: Similar as before: mark as I believe that using these markings, API documentation could be valid for both previous stable and current development versions. The added effort is modest, while going a long way towards having consistent and up-to-date documentation on the website - as such, it would resolve Cantera/cantera-website#88. PS: For the CTI/XML removal, it is probably sufficient to leave a small number of strategically selected functions that raise the necessary errors while maintaining adequate documentation during the transition. |
Closing, as there is consensus that the originally proposed idea should not be pursued. I think that using additional directives ( |
Abstract
The upcoming removal of CTI/XML will remove substantial amounts of legacy code, which affects both Cantera/cantera and Cantera/cantera-website. To date, the repositories follow separate philosophies:
and
This feature request aims for a more consistent approach that prevents bottle-necks and merge conflicts prior to releases while resolving Cantera/cantera-website#88. Code updates for Cantera 3.0 will be voluminous, so a potential change of approach is worth discussing.
Motivation
Describe the need for the proposed change:
Possible Solutions
Use the same approach for both main repository and website, i.e.
where new releases follow the same procedure as on the main repository. There won't be pushes to
stable
except for bug fixes or updates that cannot wait for the next release cycle.Some necessary tweaks in CSS for the unstable version:
<meta name="robots" content="noindex">
Some disadvantages:
Some advantages:
Other thoughts:
References
The text was updated successfully, but these errors were encountered: