Apache OpenOffice (AOO) Bugzilla – Issue 107489
Naming of installset binary files
Last modified: 2013-08-07 15:26:05 UTC
The current installset binary files have strange nameing scheme like : OOo_3.2.0_091128_ OOo_3.2.6_ and so on. Please add something like "-dev-" , "-archive-" , ... to make it easy to identify them.
before doing this please communicate with Bernd Eilers, Thorsten Bosbach and Marc Neumann to ask them to modify tooling that counts on the current file names like "cprelease", the installation automation, etc.
bei->ihi: is this really necessary? There is quite some tooling around installset binary files which is parsing the current naming scheme (and also some differently organized older naming schemes also already) which would need to be adapted if we again change this. There is for example the cprelease script used by Program Management and the InstallationSets Web Application used by Sun Engineering and various automated tests like convwatch-test, performance-test, automation-catN-tests just to name some applications which would need to be changed. The naming scheme you are talking about is only used during the building of OOo and before publishing. After Installation-Sets have been made available via the OOo Website they are quite easy to identify as what they are because when uploading to the ftp server mirror network a different naming scheme is being used and they are also clearly described on the various download webpages etc. etc. On the other hand those who are building OOo should normally already know whether they are currently working on a developer snapshot or a release on a given milestone of some current OOo codeline. IMHO there is only little extra value in a new naming scheme for installset binary files compared to the amount of work needed for adapting everything using those files to it.
no sorry, but I do not accept this. Why the heck do you wrote a "parser" to identify such weird nameing scheme but not just named them correctly from the beginning? If there are some tools matching the name then change them and thats it! It should not be that complex to match a "-dev-" or "-archive-" string , isn't it? And sorry, but we release every 3 months one set of builds, but we create billions of cws installsets per year where all and everyone wonders what kind of installset this might be. And keep in mind that they are uploaded for QA reasons etc ....
bei->ihi: please calm down and describe EXACTLY what you need and WHY you need it while avoiding unclear formulation like saying "something like" or adding "..." leaving to much room for additional guesswork of what you might mean by the reader but offering a concrete proposal for a change instead. For the getting it right at the first place argument I would like to remind you that discussion on this was open from the first time when that scheme was introduced and that everyone with additional needs like you seem to have could have gotten involved early. We have been using this scheme without complaints for a long time. It already did change a few times and our tools already have the burden to having to handle multiple naming schemes for the same files. For the getting it right at the first time part of your argument i think it is also unacceptable to require the tools and processes using these files to be able to handle not one but say 3 or maybe even 10 different formats just because somebody suddenly realizes after months or years of use that the currently used format may be not quite 100% to his/her taste. The problem is not to match on something in just one scheme like the -dev- mentioned by you but to change the used scheme multiple times and than requiring from the tools to be able to guess on which among a set of possible schemes for a given purpose actually was used by a concrete file. The possible benefit of such a change must be higher to the pain introduce by it. I just supplied my argument that the pain is probably too high and am open to hear about the possible benefit.
to make a long story short: no, we don't want change n tools 2 milestones before a release! yes, we want a new naming scheme for the OOo 3.3 release!
something like "-dev-" , "-archive-" => refers to that the experts should find a perfect nameing scheme that is 110% clear. So called it -dev- , -DEV- . -dEv- . -this_is_a_developer_build- or whatever you like but not "3.2.0_091128". Thats the meaning of "something like" !
bei->ihi: This still leaves open questions on to what the requirements actually are. So which information needs to be included and which information does not need to be included that is the question. From what I have read so far I can extract the requirements to be able to know if it might be a developer snapshot and the requirement to be able to know that it might be an archive. Anything else you would want to add to that which would not be available in the current scheme?
as far as I know we have the following builds normal , dev , archive , langpack , deb , rpm , pkg , dmg , download , non_download , sdk , openoffice , broffice , plattforms so please add this info into the naming scheme, ingo should know all the details. Another pitfall right now: - mac dmg installsets are one image file but not in the download folder ( ok , this can be discussed if this right or not ) So why not name them <product>-<plattform>-<installtype>-<packagetype>-<format>-<langs> product := OOo , BrOffice plattform := SolarisSparc , LinuxIntel .... installtype := full , langpack packagetype := normal , dev , archive format := rpm , deb , pkg , none langs := de , fr , de_fr_en-US ..... e.g. OOo_3.2-LinuxIntel-languagepack-dev-deb-de BrOffice_3.2.1-SolarisSparc-full-archive-none-pt-BR OOo_3.2-MacOSXIntel-full-normal-dmg-en-US_fr_de but Ingo might have a better overview about this matrix
ja->ihi: you might be interested into the official filename schema at http://development.openoffice.org/releases/filenames.html This schema has been created mainly to make OOo filenames compatible to the loadbalancer templates. What you're talking about is the naming scheme used at build/pack process time within the Sun build environment. Changing the internal filename representation needs coordination between several parties involved. I do not want to change this for the OOo 3.2 release. A later release may be possible but all people involved should communicate about this before we take action.
Setting target
Solved with the filename schema that was used before the project went to Apache. And here at Apache this filename schema is still valid. So, no problem anymore.