2010-06-23 07:36:24 -05:00
|
|
|
#*************************************************************************
|
|
|
|
|
#
|
|
|
|
|
# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
|
|
|
|
|
#
|
|
|
|
|
# Copyright 2000, 2010 Oracle and/or its affiliates.
|
|
|
|
|
#
|
|
|
|
|
# OpenOffice.org - a multi-platform office productivity suite
|
|
|
|
|
#
|
|
|
|
|
# This file is part of OpenOffice.org.
|
|
|
|
|
#
|
|
|
|
|
# OpenOffice.org is free software: you can redistribute it and/or modify
|
|
|
|
|
# it under the terms of the GNU Lesser General Public License version 3
|
|
|
|
|
# only, as published by the Free Software Foundation.
|
|
|
|
|
#
|
|
|
|
|
# OpenOffice.org is distributed in the hope that it will be useful,
|
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
# GNU Lesser General Public License version 3 for more details
|
|
|
|
|
# (a copy is included in the LICENSE file that accompanied this code).
|
|
|
|
|
#
|
|
|
|
|
# You should have received a copy of the GNU Lesser General Public License
|
|
|
|
|
# version 3 along with OpenOffice.org. If not, see
|
|
|
|
|
# <http://www.openoffice.org/license.html>
|
|
|
|
|
# for a copy of the LGPLv3 License.
|
|
|
|
|
#
|
|
|
|
|
#*************************************************************************
|
2010-06-22 10:21:43 -05:00
|
|
|
|
|
|
|
|
OOOBASEVERSIONMAJOR=3
|
Update to match reality
But actually, I would really love it if we could get rid of this
version.lst file. Surely we can put this information, if it has to be
hardcoded somewhere, in the same minor.mk that already contains
version information (and which, unlike this file, actually has been
kept updated by us).
Or alternatively, get rid of minor.mk and use just this file.
Best of all would be to just use the version number from the AC_INIT
in configure.in, wouldn't it? Isn't that the normal thing to do?
Also, I don't see what hardoced version timestamps as in this file are
useful for. If such a timestamp corresponds one-to-one with a version
number, the information clearly is redundant? A *build* timestamp is
another thing, that might be more useful if file timestamps or package
timestamps don't give enough information.
2011-09-21 04:49:33 -05:00
|
|
|
OOOBASEVERSIONMINOR=5
|
2010-06-25 10:56:38 -05:00
|
|
|
OOOBASEVERSIONMICRO=0
|
2010-10-29 08:55:47 -05:00
|
|
|
|
Update to match reality
But actually, I would really love it if we could get rid of this
version.lst file. Surely we can put this information, if it has to be
hardcoded somewhere, in the same minor.mk that already contains
version information (and which, unlike this file, actually has been
kept updated by us).
Or alternatively, get rid of minor.mk and use just this file.
Best of all would be to just use the version number from the AC_INIT
in configure.in, wouldn't it? Isn't that the normal thing to do?
Also, I don't see what hardoced version timestamps as in this file are
useful for. If such a timestamp corresponds one-to-one with a version
number, the information clearly is redundant? A *build* timestamp is
another thing, that might be more useful if file timestamps or package
timestamps don't give enough information.
2011-09-21 04:49:33 -05:00
|
|
|
OOOBASEVERSIONDAY=21
|
|
|
|
|
OOOBASEVERSIONMONTH=9
|
|
|
|
|
OOOBASEVERSIONYEAR=2011
|
