Fix bintray upload

[stefan-koch-sociomantic]

Simple fixup

[leandro-lucarella-sociomantic]

Also, why does it have a failing "push" travis build?

[leandro-lucarella-sociomantic]

the option should go before the arguments: beaver bintray upload -d dlang-community/apt/dfmt build/last/pkg/*.deb

[stefan-koch-sociomantic]

because I force-pushed a tag to dlang-community, I guess.

[ghost]

force push again

[leandro-lucarella-sociomantic]

Why are you pushing tags with unmerged changes?

[stefan-koch-sociomantic]

to test the bintray deployment.

[wilzbach]

Huh? Why can't you do this your fork?

[stefan-koch-sociomantic]

in my fork the deployment worked when I tested it.

[leandro-lucarella-sociomantic]

That's probably because your personal bintray repo didn't coincide with the one here (you probably had <youruser>/dfmt/dfmt instead of <youruser>/apt/dfmt.

[leandro-lucarella-sociomantic]

OK, let's move on with this. Can you please force-push again the 0.5.3 tag to its originally released commit and create a new release 0.5.4 with this merge?

[stefan-koch-sociomantic]

I can no longer remember which one the original release had

[leandro-lucarella-sociomantic]

Seriously? Who made the tag originally? It was like 2 days ago, from the list of commits in master it shouldn't be too hard to find out. Also, I just saw there is a v0.6.0-alpha.1 release that is 41 commits behind 0.5.3. Also, between 0.5.0 and 0.5.3 there were new features added. It would be nice to make release numbers have some sort of sense. Also, there is no GitHub release for 0.5.1, 0.5.2 and 0.5.3.

This is super messy. We need to regroup and do things proper here. Next release should be 0.6.0, let's forget about the 0.5.x mess and start over with some order.

[wilzbach]

This is super messy. We need to regroup and do things proper here. Next release should be 0.6.0, let's forget about the 0.5.x mess and start over with some order.

Well dfmt is tested on dlang/ci, which requires the latest, stable tag (i.e. not v0.6.0-alpha.1) to be pass its testsuite.
So after #316, I tagged 0.5.3 as I didn't want to release 0.6.0 without approval. I'm sorry about this. I would be glad if we could skip these -alpha.1 tags as

• ~>0.5.1 isn't going to match 0.6.0 anyways
• it's a lot of manual work to update the tags across all repos in dlang-community (@skl131313 even had to write a bot for it) - if we skip the -alpha.1 things, dub would take care of semantic versioning for us
• if stability is really wanted, we should have two branches

Anyhow the only public dependent repo on dfmt is dlang-tour/core which uses a locked dub.selection.json

[leandro-lucarella-sociomantic]

Well dfmt is tested on dlang/ci, which requires the latest, stable tag (i.e. not v0.6.0-alpha.1) to be pass its testsuite.

I don't know exactly what does that mean, can you send a link or something?

So after #316, I tagged 0.5.3

OK, so at least that should give us the original commit of 0.5.3.

I would be glad if we could skip these -alpha.1 tags a

OK, sorry if I'm asking a lot of very basic questions (I guess there is a mismatch here because I might assume a lot of knowledge of how we work at sociomantic and you might assume a lot of knowledge about how things work at dlang/community and I'm not all that involved in that process :).

What do you mean by skip and by -alpha.1 tags? Are there more than v0.6.0-alpha.1?

~>0.5.1 isn't going to match 0.6.0 anyways

What do you mean by match here?

it's a lot of manual work to update the tags across all repos in dlang-community

Why would we need to do that? Sorry again if I'm asking stupid questions, but I also don't use dub so I might be missing something from that side.

if stability is really wanted, we should have two branches

Yes, this is what's suggested by neptune BTW.

[wilzbach]

I don't know exactly what does that mean, can you send a link or something?

Yeah, it's not well documented:

https://github.com/dlang/ci/blob/master/vars/runPipeline.groovy#L51
https://github.com/dlang/ci/blob/master/vars/runPipeline.groovy#L417

Example from dlang/phobos#6099 -> https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fphobos/detail/PR-6099/2/pipeline/209

(it checks out 0.5.3 - not 0.6.0-alpha.1)

OK, sorry if I'm asking a lot of very basic questions (I guess there is a mismatch here because I might assume a lot of knowledge of how we work at sociomantic and you might assume a lot of knowledge about how things work at dlang/community and I'm not all that involved in that process :).

No worries, things are always under-documented at @dlang

What do you mean by skip and by -alpha.1 tags? Are there more than v0.6.0-alpha.1?

I meant that both DUB and ci.dlang.io skip/ignore/don't look at major.minor.patch- versions.

What do you mean by match here?

http://code.dlang.org/package-format?lang=sdl#version-specs

Restrict to a certain minor version: "~>2.2.13", equivalent to ">=2.2.13 <2.3.0"

Why would we need to do that? Sorry again if I'm asking stupid questions, but I also don't use dub so I might be missing something from that side.

See e.g. dlang-community/discussions#28

So at the moment every time when a PR is merged at libdparse, dsymbol etc., all repos depending on it, need to be bumped as they won't take advantage of the bug fix otherwise.
It's a real PITA and comes from fact that alpha versions are used.

I hope that helps to reduce our the barrier and differences a bit. Otherwise, just hit "reply" ;-)

[leandro-lucarella-sociomantic]

OK, I can't say I have the whole picture clear, but I think I understand the context a bit better, there seems to be a lot of interactions between projects, they are not managed very independently it seems. Anyway, I suggest to keep the discussion about how to proceed in the future, and in particular about releasing current master as 0.6.0 in #320 :)

[stefan-koch-sociomantic]

@leandro-lucarella-sociomantic @wilzbach I just fixed the v0.5.3 tag.

[leandro-lucarella-sociomantic]

Thanks!