Skip to content

Version tags should point to the official version #129

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
clintongormley opened this issue Apr 12, 2010 · 5 comments
Closed

Version tags should point to the official version #129

clintongormley opened this issue Apr 12, 2010 · 5 comments

Comments

@clintongormley
Copy link
Contributor

Hiya

When you make releases in the future, could you make the tag'ed commit include the real version number (eg 0.6.0 instead of 0.6.0-SNAPSHOT)

Otherwise there is no way to compile the official release without changing the checked out code

ta

clint
@kimchy
Copy link
Member

kimchy commented Apr 12, 2010

Yea, I was thinking about that. But then you can get the tag, make a change, compile, and it will be 0.6. I saw on other projects that they were tagging the SNAPSHOT version... .

@clintongormley
Copy link
Contributor Author

I don't know what other projects are doing, but I think if somebody downloads the source and makes changes, they should change the version number as well.

Also, if they WANT to build version 0.6.0 with their own changes, there is nothing to stop them from editing the version string anyway, so it's not providing any real protection by keeping the -SNAPSHOT suffix in there

@kimchy
Copy link
Member

kimchy commented Apr 13, 2010

Make sense, no problem. I do what my users want (you seem to occupy a big chunk of them ;) ). Will start doing it form the next release.

@clintongormley
Copy link
Contributor Author

:)

@kimchy
Copy link
Member

kimchy commented May 28, 2010

already implemented since 0.7, closing.

@bluelu bluelu mentioned this issue Dec 11, 2014
Closed
@makeyang makeyang mentioned this issue Sep 7, 2015
Closed
rmuir added a commit to rmuir/elasticsearch that referenced this issue Nov 8, 2015
@rmuir
disable securitymanager in tests, until elastic#129 is addressed in tika
9298be9
rmuir added a commit to rmuir/elasticsearch that referenced this issue Nov 8, 2015
@rmuir
Upgrade tika to 1.9. Closes elastic#129
4d22f92
C-Bish pushed a commit to C-Bish/elasticsearch that referenced this issue Mar 23, 2017
@kblincoe
Merge pull request elastic#129 from Jackbk/patch-2
0662086 
Update Coordination.md
ClaudioMFreitas pushed a commit to ClaudioMFreitas/elasticsearch-1 that referenced this issue Nov 12, 2019
Merge pull request elastic#129 from gingerwizard/master
2322c7f 
Xpack Support (inc. Shield) and Various Improvements
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
@dliappis
Add geopointshape benchmark to nightlies (elastic#418)
65137bd 
This commit adds the race configurations for the geopointshape
benchmarks as discussed in elastic/night-rally#129 (comment)

These will be run on the new group-3 (ref: elastic/elasticsearch-benchmarks#401).

The necessary visualizations, as well the Jenkins job to trigger these
will come as a separate PR.

Relates elastic#129
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
@dliappis
Visualize geopointshape benchmarks (elastic#421)
a2895b8 
Add geopointshape benchmarks on nightly/release pages and update history
of changes.

Closes elastic#129
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kimchy @clintongormley