Remove version 26 and replace with snapshot

[mizdebsk]

I think that we should reconsider how the HOWTO should be developed and versioned.

My idea is that we would be developing it only in master branch, which would reflect state of rawhide. Knowing how we love writing docs, they are unlikely to be added before corresponding code hits rawhide, so this should be fine. In (unlikely) case of new docs that need to be added for upcoming features (not yet available in rawhide), we could use feature branches. At some point of Fedora release (after branching, but before GA) we would create release branch from master. Release branch would not be changed except for major bugfixes.

If the above workflow is implemented then we should version 26 and replace it with snapshot.

Any comments or objections?

[msimacek]

IMO, I'd rather only have master branch and build multiple versions with different parameters (ifdefs and variables in docs)

The reasoning:

• We very rarely add new features. Basically the only thing which was added since f24 is gradle support. So we could easily add an if around the whole section and the few places that refer to it.
• I did a diff between master and 24 and the differences were:
  • gradle
  • dnf vs yum
  • pm_request, JDK 8 and various minor stuff which should have been there already, beacuse they apply to f24
• Most of contributions to our docs are bugfixes, clarifications of existing stuff and documenting things that should have been documented already. With the current approach, it requires cherry-picking. Even simple typo fixes have nontrivial overhead. Having a single documentation source would make improving existing documentation mcuh easier.

[mizdebsk]

We are planning two major releases, javapackages 5.0.0 and XMvn 3.0.0, in which we will add new features and change other things. Conditionals would only add unneeded complexity.

IMHO branches for released versions should only exist as snapshots of master. We don't need to keep them updated (no typo fixes, no documenting things etc.), but we can fix major bugs (like something that is totally wrong and misleading). Overhead is much smaller compared to conditionals or variables in docs.

[msimacek]

IMHO branches for released versions should only exist as snapshots of master

I thought propagation of fixes to already released rawhide was the goal of your proposal. If not, then I don't understand what it solves. Rawhide version is also a released version (from upstream POV). Why special case it? When we relese new version and add it to rawhide we should just merge the master branch to current rawhide branch.

Knowing how we love writing docs, they are unlikely to be added before corresponding code hits rawhide

Writing documentation for new features after they were already released is a bad practice. We shouldn't add workarounds like this that encourage bad practice. I'd instead propose making missing documentation a release blocker.

[mizdebsk]

This is not relevant any longer. We are not using multi-versioning any longer.