New Behave version ?

[nad56]

Do you plan soon to release a new version?
Indeed, we need to package behave for fedora and for that, we would need to have behave without nose dependency (as it is already done in the main trunk).

Thanks!

[bittner]

In relation to #855 (comment) I'd suggest to package up a 1.3.0 version as the last version to support Python 2.7, and then drop Python 2.7 support for a new version 2.0.0 to come.

This may then mark the beginning of a semantic versioning scheme adherence, with potentially more frequent, largely automated releases.

@jenisys Any comment on this?

[HenriBlacksmith]

Any plans to release 1.2.7 or 1.3.0 (or 2.0.0)?

Seems that pyproject.toml support was added, would be a nice feature to release.

[pauloxnet]

Honestly 5 years waiting for a new release is too much.
Are there any issues that really block the release of a new version?

[rkmullapudi]

Hi, yes, looking for new release. Please let us know if there is plan to release new version sometime soon?

[HenriBlacksmith]

I am wondering about the release strategy for behave?

The project is still maintained by @jenisys but I assume the master branch is not stable enough to release something?

Otherwise if atomicity of MR is guaranteed, I do not see any blocker to release?

[jenisys]

@HenriBlacksmith
The main branch (not: master, that was the old branch name) is stable and tested with CI.
The Git repository contains a number of (pre-)release tags that you can use before an official release is publish on PyPI.
The installation recipe for using Github (tags or branch) is described in the documentation.

There are some issues pending that need to be resolved before the next official release is published on PyPI.

[bittner]

There are some issues pending that need to be resolved before the next official release is published on PyPI.

Can we maybe jot down a list of those issues that need to be resolved to unblock a release? I believe, the interest of the community to get a release (actually, regular releases) out there is so big that it might be realistic to assume there will be contributors willing to go the extra mile (with PRs) just to make sure a release finally happens.

[mpinardi]

I am unsure of your timelines, but I have just completed a early version of a performance testing tool that sits on top of behave 1.2.7 (A java/js cucumber editions already exists). Could you possibility do 1.2.7-dev package release? Because as pipy does not allow direct references and as such I can't push my tool into the public repo. I was hopeful that as it took me 6 months to get this version done that you might have beaten me to the punch but that seems unlikely now.

[bittner]

I'm not 100% sure what you're referring to with "dev package release". If you intend "a release on PyPI" that will probably not happen as a dev package, according to my experience (not my choice).

OTOH, you can install the latest intended dev-release from this repository using any of the latest dev-tags (see all tags). You can integrate this in your packaging just like references to packages on PyPI. Place a line like this one in your pyproject.toml, setup.py, requirements.txt or the like (see the dependencies of behave-django for a real-world example):

behave[toml]@git+http://github.com/behave/behave.git@v1.2.7.dev5

I know, this might not seem ideal for various reasons, but that's the best choice available today, I would guess. 🤷‍♀️

[mpinardi]

Yes I meant release dev packages to PyPi such as 1.2.7-dev5.
But in regards to configuration in setup.py in the way mentioned.
PyPi does not allow this either:

 Response from https://test.pypi.org/legacy/:
         400 Invalid value for requires_dist. Error: Can't have direct dependency: 'behave[toml] @
         git+http://github.com/behave/behave@v1.2.7.dev5'

So again it seems that you can not push a release to PyPi if you reference a dependency directly.

[bittner]

Can you show the (complete) source code of your packaging setup?

According to the error message, you're using requires_dist. Why not install_requires, like below?

setup(
    name="foo-bar",
    version="1.2.3",
    install_requires=[
        "behave[toml]@git+http://github.com/behave/behave.git@v1.2.7.dev5",
    ],
    ...
)

This should work fine. Take a look at the supported syntax in the Pip documentation, otherwise.

[mpinardi]

    ...
    python_requires='>=3.9',
    install_requires=['pyee','aiofiles','behave[toml] @ git+http://github.com/behave/behave.git@v1.2.7.dev5'],
    test_suite="test"`

result

<title>400 Invalid value for requires_dist. Error: Can't have direct dependency: 'behave[toml] @ git+http://github.com/behave/behave.git@v1.2.7.dev5'</title> </head> <body>

[bittner]

Looks like you're right, because the behavior appears to be by design (2) on PyPI. Thanks for pointing this out!

@jenisys Could you push a development release to PyPI, for real? The problem also affects our project directly as I couldn't release a working state of behave-django on PyPI, which requires behave@v1.2.7.dev4. 💣

[bittner]

Related issue: behave/behave-django#158

[Johnlon]

Re New release.
I can't help but notice the lack of replies above to those asking what the release schedule is for behave.

Can we please have a reasponse here, or a link to a page, where the maintainers give a direct answer on the plans for behave.

I can only assume that, given the active commits, that the contributors are using dev builds or builds from their own forked copies?
Is that's what's going on?
If so then what is the incentive for the maintainers to make a formal release of something they consider stable?

For those of us who don't want to maintain a fork and our own build, should we consider behave as effectively dead?

That would be a pity - but we need something concrete after 6 years.

RSVP

[HenriBlacksmith]

I think @jenisys is the last active maintainer (correct me if I am wrong), I assume it is up to him to clarify the blockers which prevented him to release an actual tag all this time (and to see how contributors could help here)