• Browse GIT
• View
• Edit
• Upload
• History
• Print

UnsortedNotes

Miscellanous unsorted notes regarding the LyX developmen. Place the notes here before they are eventually move to a wiki page of their own.

1.  Types of releases

Jose wrote about releases and Christian copied it here:

Development releases that eventually lead to a stable release, e.g. LyX 1.5.0.

Alpha release

An alpha release is a release of the LyX software from the development source code at a point when only a few, if any, new major features are expected to be added before the first stable release.

Beta release

A beta release is a release of the LyX software from the development source code at a point when very few (and minor) new features are expected to be added before the first stable release.

Release candidate (prerelease)

A release candidate is a release of the LyX software from the development source code at a point when only bug fixes are expected to be added before the first stable release. If the bug fix requires a file format change then OK.

Stable releases:

Stable release

The first stable release after a development cycle. It will be followed by maintenance releases. Note that the LyX file format is guaranteed to not changed between stable releases (i.e. the first stable release and the maintenance releases).

Maintenance release

A release of the LyX software that primarily fixes bugs in the previous stable release. The LyX file format is never changed by a maintenance release.

Comparison for normal users:

• alpha => primary purpose is to help with development
• beta => daring users may try it, helping with development still major factor
• pre => should be stable enough for daily work
• stable => what users should use normally.

2.  Guidelines for file names

2.1  Bo's guidelines:

Guideline 1: Classname == file name

Because classnames are in uppercase, files are also named in this way. src/insets/*, src/mathed/* and src/graphics/* follow this guideline well so these are what I have renamed so far.

Guideline 2: Clean or merge helper files

If they cannot be merged, the name should be something like:

frontend_helper.{h,cpp}

This format will also be applied to _fwd and _pimpl and _funcs.

2.2  Andre's guidelines

If there's a single class Foo implemented in the file, it should be Foo.h/Foo.cpp. That should be the common case.

If there are classes FooSomething, FooHelper, FooSimilar in the file, it should be named Foo.h/Foo.cpp.

If there are free functions fooHelper, fooSimilar, fooOther in the file, it should be named foo.{h,cpp}.

Name clashes should be avoided.

There should be no {L,LyX,Q,QL} prefix to class and file names.

3.  Documentation files in LyXVCS:lyx-devel/trunk

• LyXVCS:lyx-devel/trunk/README - this is to be read first by someone using the source. It should give pointers about where to go next.
• LyXVCS:lyx-devel/trunk/ANNOUNCE - the source/copy of the announcement that's sent out at the time of a new version is released.
• LyXVCS:lyx-devel/trunk/NEWS - a collection of major points from the previous announcments, presented in reverse chronological order.
• LyXVCS:lyx-devel/trunk/RELEASE-NOTES - Important things to know about present release. This includes known bugs that have not been fixed.

4.  Branches...

Just a place to note a link to the NetBSD's branches:

• http://www.netbsd.org/releases/release-map.html

I wonder how they relate to whatever system we use... /Christian

5.  Miscellaneous links

5.1  PhD thesis on release management in open source projects.

5.2  On the evolution of the user interface of MS Word

5.3  Creating a dialog from scratch

URL: http://www.lyx.org/trac/changeset/25144

Log: Preliminar InsetInfo dialog. This was done as an exercise to show Bo (an others) how easy it is to create a new dialog. This dialog needs to be filled in, right now, there is just an OK button.

LyXDevelThread:108286

5.4  On the origins of TeX

Pavel sent the following to the developers' list:

Category: Development, Misc