[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] 1.17 Release - Call for documentation updates !



Am 08.08.2010, 06:22 Uhr, schrieb Paul Wratt <paul.wratt@gmail.com>:

On Sun, Aug 8, 2010 at 7:06 AM, David Gálvez <dgalvez75@gmail.com> wrote:
2010/8/7 Paul Wratt <paul.wratt@gmail.com>:
On Sun, Aug 8, 2010 at 3:19 AM, David Gálvez <dgalvez75@gmail.com> wrote:
2010/8/7 Alan Hourihane <alanh@fairlite.co.uk>:
Will MiNT be installed in 1-17-cur or 1-17?

Following current trend it should be 1-17-cur.


For this kernel release, shouldn't the system directory be 1-17 or
1-17-0?, i thought that "cur" was used for CVS test versions.

it will check a versions specific folder, if not found, it will look
for -cur (1-17-cur)

I don't think it will behave like this.

I guess that after modifying  /buildinfo/version.h, the kernel will
look for his system directory in /mint/1-17-0
and if not found in /mint/, and if not found it will stop.
"-cur" is for CVS alpha builds only.

http://sparemint.org/cgi-bin/cvsweb/freemint/sys/buildinfo/version.h?rev=1.14&content-type=text/x-cvsweb-markup

Which status will have this build beta or release?

I see what you mean, and I guess it depends on how Alan tags the point release.

BTW if -cur is not found, it looks in /mint before exiting

I would actually prefer if a non-cvs release would also check -cur as
well, as this affects config files in a positive way (ie no need to
change MINT.CNF and XAAES.CNF between versions), like 1.16.3 does
(maybe that is becuse it is a cvs build, not a release build)

I guess the idea is: release starts from 1-17, cvs-build from 1-17-cur. So you can add new features in the cur-version without having to care if they break the last release. There must be some place in the kernel-source that does this.


--
Helmut Karlowski