Would you consider tagging v0.11.0?
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 1/5
- Tempo estimado
- Menos de uma hora
- Facilidade para iniciantes
- 15/100
- Tipo de issue
- Funcionalidade
- Clareza
- Claramente especificada
- Status de atividade
- Ativa
- Stack de tecnologia
- cmake, cpp
- Domínio
- build-system, release
Direção de pesquisa
This is a maintainer action, not a code change: the version 0.11.0 is already declared in CMakeLists.txt and meson.build, but no v0.11.0 git tag exists. Check that both files show 0.11.0 on the target commit, then a maintainer with push rights would create and push the tag. Done when v0.11.0 points at a commit whose build files declare that version.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Hi! I'm working on the ConanCenter package for stdexec (conan-io/conan-center-index#30060), and I wanted to ask whether you'd consider tagging a release. It would help us a lot.
Since #2116, both CMakeLists.txt and meson.build declare 0.11.0, but there's no tag for it yet. The existing tags (nvhpc-*, gtc-2026) aren't version numbers, so each package manager ends up making one up. vcpkg ships version-date: 2026-05-25, and ConanCenter would have to publish 0.0.0.cci.<date>. Each one points at a different commit, which makes it hard for users to know which stdexec version they actually have.
Would it be possible to tag v0.11.0? If it could happen after #2341 is merged, even better. The tagged sources could then be configured and installed without network access, and ConanCenter could package that tag directly without patches.
For future releases, whatever cadence works best for you is fine by us. Even tagging alongside the nvhpc-* snapshots would already be great, as long as the version in CMakeLists.txt and meson.build gets bumped first.
Thanks a lot for considering it, and for all the work on stdexec!
- Linguagem predominante
- C++
- Estrelas
- 2.5k
- Forks
- 277
- Merge médio
- 1d 16h
- PRs com merge (30d)
- 63
Preparar o ambiente
Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de NVIDIA/stdexec
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
NVIDIA/stdexec#1751 · 3 comentários ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 12/100
NVIDIA/stdexec#2344 · 4 comentários ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 15/100
NVIDIA/stdexec#2337 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 54/100
Mantenedores costumam responder em até 1 dia
Todas as issues de NVIDIA/stdexec
Issues semelhantes
-
(S1 - Need confirmation)
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
CleverRaven/Cataclysm-DDA#89194 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
moonshine-ai/moonshine#231 ·
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
Mantenedores costumam responder em até 1 dia
-
documentation good first issue M7: multi-node no hardware needed
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 95/100
GageLawton/noise-cancellation#299 ·
Mantenedores costumam responder em até 1 dia