On Sat, 14 Sep 2013 11:59:57 GMT, Jacob Carlborg wrote:

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.

Since the default build type is "debug" that should definitely be included. Executing the equivalent of "dub build" and "dub build --build=release" for each newly installed package would basically do this. Once a better build system is in place that would be an option.

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 think translated to D we can then just store a build per combination of version flags (and probably debug version flags). Different "configurations" could then end up in the same folder, but if all parameters are the same there is no reason to put the result into a different folder.

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.

Difficult call with the branches and starting tracking just after the first version tag. It would be a lot cleaner, but on the other hand there are a lot of packages now where the author doesn't feel comfortable yet to start tagging versions (even if that is an unjustified feeling). IF we end up with half the number of packages by forcing version tags, that would arguably be worse overall for the system.

Hmm.. maybe a little psychological trick can help here: non-tagged packages could always occur after tagged packages in the list (assuming that they are in a pre-release state) or get some kind of visual "beta" tag, so that the author is kindly forced to start making tagged versions to get more people to use their packages.

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".

True, but I also often have the situation with vibe.d that a quick fix is needed for someone and making a release would be too much effort. But maybe in that situation I should start thinking more about pre-release versions (e.g. "0.7.18-pre.1"). I'm not even sure if and how these are currently matched by DUB when using ">=0.7.17".

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.

I agree. Currently it encourages version based usage not strong enough.