Versioning would be wise

[pkg]

Versioning would be wise

[eikenb]

For those who care, once all the current major issues have been ironed out I plan on tagging an initial version. Not sure if I'll call it 1.0, but at least it will be a known state you can pin your code to.

[davecheney]

I'm happy to tag a release of this package.

[xor-gate]

Maybe an idea is to branch from a point where everything "is stable" into v1 and then when some fixes (no api changes) need to be done they can be cherrypicked or patched in the branch? As a extra feature this v1 branch can have tags like v1.0.0, v1.0.1, etcetera. As per www.semver.org. Then when v2 is ready we could branch from master and then tag as appropriate.

[davecheney]

I don't think this package is 1.0 ready, but I'll tag a version soon.

[xor-gate]

A v0 branch/tag could also be made. As people are using the sftp package in "production" already (the "old" api). You are right, maybe with the upcomming new architecture we should move into v1

[davecheney]

I'm sorry about the breakage, I'll tag a version soon.

[xor-gate]

No problem, there are multiple ways to fix things. But most people who currently use sftp without vendorizing will scratch their heads. It would be wise to mention in the README how we will handle versioning in the future (semantic versioning, tags, branches) so developers will be less annoyed :-). And people then can use the http://gopkg.in service to directly include it in their go projects.

[davecheney]

@xor-gate yes, I understand this, I'm not happy about the lack of support for versioning in the go tooling either.

[xor-gate]

We hope for the best in the future, the nice thing with the tooling is you will not be enforced to have some style but it would be nice to have something standarized (godep, gopkg.in and others feel a bit like a hack). But for the upcoming time it would be wise to mention the development flow in the readme (or docs) of the package itself.

Thanks for your understanding 👍

[joeblew99]

If this is stable can it be released for now ?

[davecheney]

I'm not ready to tag a release yet. I'm sorry but I have no date when I
expect to be ready.

On Sat, 20 Feb 2016, 03:19 jow blew [email protected] wrote:

If this is stable can it be released for now ?

—
Reply to this email directly or view it on GitHub
#86 (comment).

[joeblew99]

ok. I have a use case where i need to only pull data from a sftp server. Any idea if this functionality works currently ?

[davecheney]

sgtm.

…

On Thu, Mar 2, 2017 at 3:03 PM, John Eikenberry ***@***.***> wrote: For those who care, once all the current major issues have been ironed out I plan on tagging an initial version. Not sure if I'll call it 1.0, but at least it will be a known state you can pin your code to. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#86 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAxdIuc6WVegnIz4Mf-KbnRN3bNYvks5rhj97gaJpZM4HGu14> .

[fd0]

What's the state of a release tag here? For restic, we'll switch to dep shortly, and it would be very helpful if you could tag a release. Thanks!

[eikenb]

I'll look into doing it this next week. The bug reports have calmed down and there are currently no outstanding bugs that I haven't addressed in some way.

FYI does anyone care about the versioning scheme? SemVer seems the best default for this sort of project, so I'll probably just go with that.

[fd0]

Please use semantic versioning (aka "1.2.3"), that's what the upcoming dep prefers. Thanks!

[xor-gate]

Semver would be a good choice, as most people know it in opensource projects.

[eikenb]

Semver it shall be... in a few more days. I want to nail down my revised code for the file-listing in the request based server (#184) as it will break backwards compatibility. Once I have that merged I'll tag the version.

[fd0]

Awesome!

[eikenb]

Sorry for the delays. I am going to tag a version soon. Just another influx of tickets makes me want to review them to be sure.

[eikenb]

I keep putting this off in expectation of a breaking API bug... but I need to get over it and just do it. So this is it.
I tagged the current head 1.0.0 (semantic versioning) and things are now versioned.

[xor-gate]

When the API compat gets broken you just bump the major version, no problem at all. Great you tagged the first release. Congrats :+). Now people who are going to use tooling can just refer to this one without breaking stuff by pulling master.