On 5/1/17, 2:00 PM, "Bolke de Bruin" <bdbr...@gmail.com> wrote: > >In Python we are used to install through so called source distributions >“sdist”. Package managers (e.g. pip) use the filename to determine >whether to download a new package and if they do they examine the >contents of the package to find out it they need to install the package. >They do this by examining the version contained inside the package. Thus >while a different filename will trigger a new download, it might not >install updated parts of the package. This is different from your example >as no installer is examining both the name of the tar ball and the >contents of your javascript files for a version identifier. > >But maybe you have a point. We could just do a "git clone”, update the >version (not push it to git until final release), tar it. We then ask >people to vote on it. Then we could provide the convenience package (that >everyone will use) next to it. Or if we consider the “sdist” a binary >release officially we vote on that one as well after the first vote. Two >downsides to this are: if only option 1) nobody would user the tar, as >the sdist is essentially the same and works with the package managers. >Might be a bit excessive? 2) that would be a 2+2 vote again. > >Option 1 could work, it isn’t ideal, but will satisfy the procedure.
Many projects produce two packages: the actual sources, and something most customers want to use. The main reason ASF projects focus on the source is because we are an "Open Source" foundation, but also because you can verify that a source package isn't infected by a virus more easily than reviewing other kinds of files. AIUI, there are customers who are concerned enough about the safety of a release that they only work with source packages and compile everything from source. So, whatever you call your "source" package that is officially voted on must meet this criteria. The customer package can be collection of files, but it must meet certain requirements like having a LICENSE and NOTICE and detached signature that the voters verify. Many release examiners want to verify the source package against a Git hash or SVN tag. That isn't a "must do", but a good thing if you can do it. So, I'm not sure delaying pushing the tag is a good idea. What we do in our project is pick whatever hash is the point in history for the release and tag is as RC1, then when the vote passes, tag whatever hash finally passes with the release tag. So, if an sdist is entirely source, IMO, you can just make two sdist packages (one for customers and one with "RC1" appended to the version number) and offer both to the voters. If the voters can easily validate that the RC1 version they test is essentially the same as the other package, then I think you are good to go. HTH, -Alex
