> Shouldn't we start with 2.1 first?

Yes.

>
> I guess there will still be 2.0.x bug fix release an that Jürgen will keep 
> maintain them.

We should ask Jurgen whether he wants to continue doing this job, then we
should query whether there are other candidates and then we would need to
organize a voting...

.. I'm kidding now (of course).

>
> I'd like to propose that 2.x release are only about GUI improvements and code 
> cleanup. IOW 2.x should keep the file format unchanged.
>
> 3.0 would in this scheme introduce a new file format, maybe XML, maybe not.
>

You're just moving up the minor/major version ? That would make sense,
though it's a bit nasty to wait for 10 years to fix a bug that needs
a little file format change.

Or do you mean a file-format change in the sense of the transition to XML ?

I'd prefer to continue with the current versioning scheme and introduce
LyX3.0 when there is a significant change, or when we think LyX has taken
another step in maturity.

> I'd like also to propose that we switch to git now for 2.1 and than svn is 
> kept only for 2.0.x bug fixing... At this point we should have one branch per 
> new GUI feature or code cleanup; this branch will be merged only if complete. 
> This will help 2.x to remain stable despite the incremental
> improvements.

It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months.
However, everyone needs to become used to using git, we need to decide on
a place to host the git repo, the maintainer needs to design a appropriate
workflow that we all agree on.

For this I've tried to adopt the Git development model:

- All new commits are committed into a feature branch:
  e.g.:
     vfr/fix-table-width, baum/layout-translations, younes/redo-spellchecker-ui 
...
- These features are regularly merged into a development branch.
- When a feature is complete, well tested, well documented, has a test
  accompanied with it and when it has clear commit logs, the feature can be
  merged into either experimental/trunk/maintenance and so forth.

Git uses another level in-between, but I think that is a bit too much
given the fact that there are not that many developers testing other one's
features to the bone. We just don't have manpower to do that.

There are certainly benefits.
- Less noise in commits: a new feature in SVN sometimes comprises over 20
  commits or so. When using Git, we can cook a certain feature until it is
  complete and commit it as 1 merge consisting of a number of commits which
  are logical steps in introducing a feature. As a result we have less commits 
in
  history saying: "Fix thinko in previous commit."; or "Fix bug #xxxx." which is
  a bug which would never have existed if it wouldn't be introduced in SVN in
  the first place; or "Add a comment for rxxxxx"; or "Revert commit rxxxx"; or
  "Revert unwanted commits in rxxxx" and so forth.
- It's easier to backport certain features to older branches.
- We can think of having several branches: e.g., LyX3.0 (or experimental)
  /LyX2.1 (or development)/LyX2.0.1(or maintenance)
- A clearer separation of commits to docs, translations, layouts, etc from
  commits to the cpp code.

>From my first experiments it seems that in the last few months, there are
only 20-30 topic branches needed. All commits are related to each other
within a certain feature or are 'development' commits like cmake/makefiles/
installers/release-notes/credits or are commits to doc/translations/layouts
and so forth.

Furthermore, we should have a clear development strategy. We need to
track which features we aim to introduce for the next release, we need
to keep track of the status for each of the features, so we can either
decide to drop the feature or decide to draw attention to it and speed
up development. Now, it happens that there are half-baked features in
trunk... and we have a problem when a release approaches to get them
either in a reasonable state or to remove (disable) them.

Opinions ?

(Writing this took some time, so I missed out on the other comments in
the other thread. Don't mind starting a new thread again. )

Vincent

Reply via email to