On Tuesday 27 January 2004 20.27, Branko Čibej wrote:
> Jostein Chr. Andersen wrote:
> >The packages too? I have used the installer source from the trunk all
> > the time (while the branched code have been older and older).
> >The only win32 installer code that works is that one in the trunk
> > (it's even the most stable installer so far :-).
> This is not a good situation. IMHO the installer on the branch should
> be kept up-to-date -- remember, Win32 build on the trunk is already
> significantly different than the one on the branch (trunk uses APR
I have been asking about how to handle this both on IRC and several times
on the dev list without getting any response, thanks :-)
So let's branch from the 0.37.0 tag and make a new STATUS file so I
> > can write an item there as soon as possible (I do even have more
> > changes to do there before 1.0).
> I disagree; simply merge from tags/0.37.0 to branches/1.0.x.
The inno setup in tags/0.37.0 are outdated, the inno setup in the trunk
are a perfect match for 0.37.0 and (have you noticed: -Not a single
problem or complain about the Windows installer this time? :-)
> >Please, remember that packages/installers are made _after_ the
> > tarball. Changes in this might occure after a release tag.
> I really don't know why this is necessary. All necessary changes to
> installers should be made on the release branch before the release is
> tagged, otherwise people can't make their own packages from the
> tarball. That's weird
In my case, the Windows installer are made after you have made the
binaries. Hopefully, some bindings will come on regular basis (jave,
perl)as well so I can make a full Installer as well.
The thing is that I really don't know what to include in the installer
every time it's created.
> We can do this at least for Windows, where the package maintainer and
> release manager are the same person. :-)
Me to (RM have a multi personality... ..oh, so do I, cool! ;-)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jan 27 20:53:10 2004