On 4 April 2016 at 21:14, Vladimir Sitnikov <[email protected]> wrote: > sebb>I just don't think we should be expected to help with this beyond > sebb>providing the information needed to download JMeter. > Sebb, I think JMeter should provide users an ability to stick with a > specific version.
That is already possible. If a user downloads a copy of JMeter, it will be available until they delete it. If they do accidentally delete it, then they can get it again quite easily. > It is crucial for reproducible tests. Unexpected flips of JMeter > versions would be bad. It is not our problem if they start using a different version of JMeter. We have no control over that, nor any responsibility. > There are cases when "new version" breaks here and there as there are > just way too many > moving samplers. That may be true but is not relevant to how JMeter is made available. > I would not say JMeter breaks often, however I was personally bitten > by those issues. Ditto. > Being able to ship multiple versions would simplify "try 3.0" kind of > scenarios. We already provide all the published versions. For all ASF projects. Since the ASF started. > Bintray is a well-known distribution facility. > It provides binary distribution for free for OSS projects, so I see absolutely > no reason to ignore it. I did not say ignore it, but it is out of scope for the JMeter project. > Are there objections on not providing bintray binaries? Yes, it is out of scope for the project. > Apache Groovy uses bintray, so it should be doable. Of course it is doable. But it's not in scope for the JMeter project. > There are three tasks: > 0) Configure bintray repository owner somehow > 1) Integrate bintray publish action into release process > 2) Publish previous versions Sorry, but these tasks are out of scope for the JMeter project. > Vladimir
