Release cadence

[sagikazarmark]

I know this has been brought up in the past, but a clearly communicated release cadence could help users a lot who wants to rely on sftpgo. Milestones, X month release cycle, or "on-demand" all work and help people understand what to expect.

Otherwise every now and then you'll receive an issue with a New release? title. 🙂

[drakkan]

Well, I generally consider Git master the best and most stable version, you should all use it :)

I don't use SFTPGo in production myself so I generally would like to wait for some time to get bug reports and after 1.0 I did a big refactoring to add multi protocol support (FTP and WebDAV are not included in 1.0.0).

Currently I have also less time to work on the project.

I think SFTP support is in good shape and it is ready for a new release (it should be much better than 1.0.0). WebDAV and FTP could be improved but honestly I don't have a plan. Better docker support would be good to have to, see #161

I work on this project based on my free time, sorry

[sagikazarmark]

Well, that's okay, it's open source. 🙂

FYI I'm considering using sftpgo in production (only the sftp part). I might be able to contribute the Dockerfile and Helm chart and share some information about running it in prod.

[sagikazarmark]

Thanks for the great project BTW. 🙂

[drakkan]

Well, that's okay, it's open source.

FYI I'm considering using sftpgo in production (only the sftp part).

I think you shouldn't have big issues, several users already use it in production, I recommend using Git master and please report any problems

I might be able to contribute the Dockerfile and Helm chart and share some information about running it in prod.

That would be great! Thank you

[wkoszek]

@sagikazarmark @drakkan Dockerfile in master would be very nice.

[drakkan]

Hi,

since 1.0.0 we added the following new features:

• Optional support for FTP/S and WebDAV
• Added a post login hook.
• Added support for limiting the size of a single upload.
• Supported protocols (SSH,FTP,WebDAV) can be enabled/disabled per-user.
• Added examples for one-time password login using Twillo Authy.
• Added generators for shell completions and man pages.
• Added some how-to style documents.
• SFTP: added readlink support.
• SFTP: added lstat support.
• SFTP: allow to globally disable password logins.
• SFTP: fixed truncate support.
• Debian and RPM packages are now automatically built after each commit/tag.
• Other minor fixes.

I think we are ready for 1.1.0 release. I'll tag a new release before the end of the next week.

There are some things that I would like to support but I have no enough time now and they could be added later, for example:

• improve FTP support, see for example https://github.com/fclairamb/ftpserverlib/issues/173 but there are other things to improve too
• add dead properties support for WebDAV
• azure blob storage backend (I don't have an account and I can get a free account only for 12 months)
• SFTP as storage backend too
• add statvfs support, I have to add this support to pkg/sftp first
• improve docker support and add an official docker image
• explore versioning support for S3 and GCS

thank you

[sagikazarmark]

Sounds great, thanks a lot @drakkan!

I think it would make sense to also provide an official Docker image with everything enabled by default.

GitHub provides a free container registry: https://github.blog/2020-09-01-introducing-github-container-registry/

I'd be happy to provide a PR with a dockerfile and the necessary GHA changes if you like the idea.

[drakkan]

Sounds great, thanks a lot @drakkan!

I think it would make sense to also provide an official Docker image with everything enabled by default.

GitHub provides a free container registry: https://github.blog/2020-09-01-introducing-github-container-registry/

I'd be happy to provide a PR with a dockerfile and the necessary GHA changes if you like the idea.

Hi, if you want to work on this I would be happy to wait for your PR before the next release, thank you!

Since all configuration parameters can be enabled/disabled via env vars (thank you for working on viper), we could enable SFTP as default and the users that need FTP/WebDAV could enable them via env vars, what do you think about?

[sagikazarmark]

Since all configuration parameters can be enabled/disabled via env vars (thank you for working on viper), we could enable SFTP as default and the users that need FTP/WebDAV could enable them via env vars, what do you think about?

I actually meant compiling every module into the app (I know certain parts can be disabled with build tags). Then users should be able to configure everything they want.

[drakkan]

Since all configuration parameters can be enabled/disabled via env vars (thank you for working on viper), we could enable SFTP as default and the users that need FTP/WebDAV could enable them via env vars, what do you think about?

I actually meant compiling every module into the app (I know certain parts can be disabled with build tags). Then users should be able to configure everything they want.

Yes, I agree, we should compile all the features by default

[sagikazarmark]

See #180

[sagikazarmark]

@wkoszek here you go: https://github.com/users/drakkan/packages/container/package/sftpgo

Let us know what you think!

[wkoszek]

@sagikazarmark It looks solid, thanks. I'd love to see it using a .deb or .apk package, so that the setup steps aren't replicated. I think it'd reduce the Dockerfile complexity significantly.

[sagikazarmark]

I think it'd reduce the Dockerfile complexity significantly.

I don't think it would/should affect the docker build.

[wkoszek]

@sagikazarmark Let me rephrase: I never see replication of setup steps in Dockerfile as a good thing. I worry that keeping Dockerfile in sync with deb's pre/post run scripts is error prone, and correct me if I'm wrong, but now they are. IMO we should strive to have Dockerfile follow normal Dockerfile format:

1. Add SFTPGO's PPA in Dockerfile and refresh the /etc/app/lists
2. apt-get update && apt-get install sftpgo

[sagikazarmark]

@wkoszek I'm not sure what "normal" Dockerfile format means, but I'm pretty sure that's not it. 🙂

The idea behind a self-contained docker file is that you can easily build a container image from the source and ship it, which is not possible if you rely on a package repository to install the software. (You certainly won't upload a deb with a custom, patched version, just to download it again)

If you take a look at how software is built and shipped in container images: none of them wait for the CI to upload a deb, just to download it again.

I'm obviously biased as I rarely install applications as OS packages anymore, I primarily run containers, so I don't even need those distribution formats. 🙂

[drakkan]

v1.1.0 is now released.

For future reference, there isn't a fixed release cadence. We have to accumulate enough new feature before tagging a new release, thank you!

[sagikazarmark]

🎉 Awesome, thanks!

For future reference, there isn't a fixed release cadence. We have to accumulate enough new feature before tagging a new release, thank you!

I'd probably add that to the readme somewhere 🙂