On Wed, 11 Sep 2013 10:37:13 GMT, Sönke Ludwig wrote:

Use the NNTP interface! (Just saying that because I started adding email notifications almost a year ago, but never got the guts to finish them ;))

I tried using the NNTP interface but it says I need to log in to post to the server. I can't see how to specify a password in Thunderbird :(

That and possibly other compiler flags, depending on the desired use case (e.g. debug vs. release version or the variant of an external link dependency that is used). But already all combinations of compiler (version), architecture and version flags can be far too many to install them all by default -- but if we accept that, we are back to caching compiled binaries lazily (and maybe compiling some kind of default configuration eagerly if desired), which is exactly what is planned.

Obviously not all combinations cannot be installed by default. I was thinking a release build should be installed, possibly a version with debug symbols enabled. I don't know how useful installing a debug build would be. I think one have to assume that the packages used are working perfectly. If some package doesn't, then one can start installing debug builds or similar.

This is more or less what I have in mind, except that binaries would be put into a directory that is unique for all aspects that affect binary generation (i.e. the above) instead of only the architecture. Or rather into multiple directories, each for one combination. The unique part could be a hash value of all related factors or we could try to get something human readable, such as "(compiler)-(compiler version)-(os)-(arch)-(configuration)-..."

Ok, I see.

DUB has "configurations", but only one configuration can be active at a time for each package. But the latter variant using a sub directory is what I'm also imagining (just using a scheme that includes all aspects as mentioned above).

I'm not 100% sure how MacPorts work when you need to install an additional variant. But several variants are possibly to combine. Say you have a library for manipulating images. By default it will build support JPEG and PNG. Variants exist for GIF and PSD as well. Of course all these variants will need to be able to be used together.

I don't know how "configurations" work in DUB but if variants corresponds to -version flags there is no problem with multiple variants. Just append all version flags, "-version=GIF -version=PSD -version=JPEG" and so on.

If you have only installed two variants out of four. Then need to install additional variants I would imagine it would just rebuild the library with the old variants and the newly added ones.

I MacPorts you can have multiple versions of a package installed but only have one active. What it does is that it will install the package in a path which is not accessed by default from PATH or the paths looked in for libraries. When setting a package to active it will create symbolic or hard links.

I agree that "~issue/2" should at least never be the default - this needs to be changed so that "~master" comes first. However, it's difficult to say what should be available. For example, there may be a "~2.x-devel" or a "~stable" branch that may very well make sense to use in some situations.

In general I agree of course that versioned releases are by far preferable, but during early development, or when having tightly coupled packages, it can be necessary to work on branches. I just don't want to make that impossible or force more structure/process on developers than necessary.

I would make it possible to in the registry specify which versions and branches are available. There could also be a flag in the registry to turn off default tracking of version tags and branches. Then one need to manually add them. I would also change so that by default you need to push a version tag before dub starts tracking that package.

Note that I'm not talking about uploading zip archives or similar. I'm talking about just be able to specify for the registry that only these three tags and this one branch is available.

The semantic versioning scheme says what you can and cannot break when making a new release. But it also basically says that you can break how much you want in between releases.

I don't like if some starts using a non-released version of any of my packages, then says: "hey you broke the library in the last commit". If dub uses the master branch by default then I can't say "don't use HEAD, stick with releases".

Using Bundler the standard way is to specify versions, which are downloaded from RubyGems. It's also possibly to specify a git repository, pointing to a branch, tag or any commit. But doing the latter you're kind of on own your own and have to accept possibly code breakage in any new commit.

Short summary: use in between releases on your own risk. I don't think dub should encourage this.

/Jacob Carlborg