Create a tag #39
Comments
|
We've never once broken backwards compatibility on mapstructure and don't plan to, versions are unnecessary here. |
|
Not tagging sources makes it difficult to package as any package will have a made up version. For things like Gentoo this makes it even more difficult as I showed with the link to the ebuild. If you make any modifications, someone has to manually re-emerge the package as 9999 ebuilds are not updated, the version never increases to say 99999. So one has to re-emerge that every time. Its not ideal. All things need to be versioned so they can be packaged. Breaking compatibility is another matter. On Gentoo that would mean the package is slotted. Even if you never break compatibility there might be different versions in the same slot. A package might work with one and not there other. It is not wise to put software out there much less others use unversioned stuff. It creates allot of issues. However it seems you are opposed to such. I will see if Rackspace developers can use a different library for gophercloud. I do not think any package maintainer will like depending on an unversioned piece of software. Anyway thanks for the consideration.... |
|
Also, the package isn't unversioned, it just simply won't ever break backwards compatibility. A lot of our ecosystem personally as well as a decent number of Go projects in general depend on this library and so I couldn't break compatibility. The package has existed perhaps 2 years-ish and we've never broken backwards compatibility and never will (we'd fork into "mapstructure2" or something). If it helps, I've pushed the tag "a-wrinkle-in-time" that you can use. |
|
(Note, I didn't name the tag a version number because I don't want people to think it means anything. We don't break backwards compat, and we have benchmark tests to not regress on performance either.) |
|
I don't even know where to begin with this, you are experienced enough to know the reason and significance of version numbers. What if you fix a bug, how are others to know you fixed that bug? There are so many reasons its hard to know where to begin. Also the tag of a-wrinkle-in-time really does little, its still not a version, a numeric number that will increase over time. https://en.wikipedia.org/wiki/Software_versioning Though really I did not think this to be a major request, and quite shocked at the resistance, then turn around and make an odd tag etc... I was just filing this on behalf of others anyway. I rather stay clear of this madness myself... Thank you and have a nice day! |
|
Yes, I'm sorry. I don't believe in this for Go libraries that never plan on breaking compatibility. (On the other hand, for those that do, I'm a big fan). I don't want to block others out from using this, but its so unnecessary and this whole argument on its own is silly and unnecessary. To appease you, I've pushed "v1.0". I hope that helps quell your concerns. I may never change tags again, but you can be rest assured that version will work for all time. Ultimately, I think its still silly, but if it helps you move forward and I only have to type that command once, there you go. |
|
I also apologize for my stubbornness, I don't want to push you away and I don't mean to be negative. |
|
I am going to let it ride I code in Java mostly and also C. I haven't time for this really. I must say it has put me off of Go some what. If libraries like this others will use will have a practice of not being tagged when bugs are fixed, new code, etc. Its not a compatibility issue, that is another matter. Why you have major, minor, patch, etc. I was just packaging this for others to use. Thus this is an issue others will face I was trying to help out with. I am not trying to change your development style, or tell you how to version, release, or run your project. I myself would NEVER code against unversioned code period. But that is me, to each their own. No worries, not trying to go back and forth. I accepted your initial response of no. |
|
Understood, sorry about that. I've deleted the tag if you're not going to use it. Let me know if that ever changes. |
|
If tagging is not something done as part of normal project development on a routine basis, then its really of no use to me or others. |
|
Agreed. Good luck, and I'm sorry we couldn't come to a resolution for this. |
|
No worries, I am not coding in Go or against this library. I was just packaging Rackspace new CLI "rack" which depends on gophercloud. Which gophercloud in turn uses mapstructure. It is up to Rackspace how they proceed. It is all moot to me. Thanks for the tag you created and removed, though it wasn't really usable for the needs I was trying to address. I also created a ticket for perigree, that has a 0.0.0 tag, but gopher does not compile against that, but does against head, thus I opened a similar ticket. I suspect that one will get a new tag as it seems part of their development process. As gophercloud is also tagged/versioned, and so is rack. This is really the first piece of software I have ever seen not versioned. That others are using unversioned software is even odder. However it seems its part of Go. Thus I will likely avoid Go, despite starting to like it and was considering coding in Go for future projects. I will stick with Java and its mature libraries that are all versioned, as is just about any C library or most any code I touch and use. Thanks again and have a nice day! |
|
@mitchellh May you put information to README that public API and behaviour is stable and no breaking changes are expected? |
Can a tag be created of this so that dependent packages can pull a specific version rather than having to use current sources? That would be much appreciated!
While this shows a 0.1, I made that version up. You can see in the ebuild it pulls the master.zip file rather than a tagged version.
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-go/mapstructure/mapstructure-0.1.ebuild
The text was updated successfully, but these errors were encountered: