Use github.com releases and tags about core HOT 17 CLOSED

• It's not yet fully hosted on GitHub, the binary releases are still uploaded to and served from sf.net.
• Tagging nightly releases is IMO overkill and confusing. Retrofitting Git tags for previous stable release could make sense (though all source archives are accessible from sf.net), question who wants to do it.
• For syncing sources with binaries, the key would be to properly version binary releases with a Git commit hash, which is yet to be solved. I've implemented the core part of the logic in my fork.
• Stable and nightly version download locations are all well documented in the README, with links.

from core.

So the objective is to really make this migration to GitHub, right ?

Is there a roadmap anywhere ?

Tagging nightly releases is IMO overkill and confusing.

I say to tag stable and dev releases. At least the latest stable release, 3.0.0.

from core.

There is no roadmap, at least not a public one that I know of, sorry.

Fully abandoning sf.net sounds nice in theory, yes.

A year ago - at migration time - GitHub didn't have a binary release facility. Now they have some support for it, though it doesn't seem to be suited for automated nightly releases, but it might be used for future binary releases. Finally to fully move here, all existing sf.net release would need to be migrated here, which is at best tedious task and will most probably make finding binaries confusing.

Another option is to use the web area to store binaries, along with a web page for navigation, probably a better way to go, though again not suited for nightly binaries due to the excessive repository size it would implicate.

There are no 'dev' releases besides the "nightly", but it's not a release, just a binary build. Tagging that in Git repo makes no sense. It should be done the other way round.

from core.

[ On a side note, I think development of Harbour doesn't benefit from the 'nightly' binary releases much overall, yet it poses multiple technical burdens, so even though it wouldn't be popular with some users (not Harbour developers), it's also a possibility to simply stop doing them on sf.net or GitHub via "official" channel, and "outsource" the handling of the problem to volunteers and users interested in it. It would need a 24/7 internet facing web server with support for automated uploads (unless it is the same machine creating the build). This could be a Windows machine at any cloud provider, but it means it won't be free. Again, something for project maintainers to decide. Any of these involve a certain amount of effort though. ]

from core.

The API supports releases (https://developer.github.com/v3/repos/releases/), if that's what you meant
about automation.

Harbour could have a nightly binary for each supported platform made permanent in a release named "nightly-release".

And about the confusion about download places, starting from the next stable version, the repo should be tagged, for those who want's do build from source, and binary releases for each supported platform (.exe, .deb., .rpm, ...) should be made public with the "Release" feature from github.

About the roadmap, is important to guide those who want to contribute, working on things like these without knowing if thats the project goal, stops us from starting.

I think that the web area for the releases is not an option.

from core.

I meant that, but I could not make it work, plus it is heavily designed towards versioned builds, not daily updates for the same version (by 'version' I mean 'dev'). Anyhow someone will have to make a successful test then develop the scripts and deploy them, etc.

"Each platform": The difficulty is to build them, daily. I find it idiotic to provide even Windows builds daily, as I told, because they don't result in better or more valuable feedback for dev version, instead they raise the level of generic (user-oriented) support noise. IOW it's a lot of work/resources for developers and minimal if any benefit. Making automated build systems is not trivial and also needs machine resources, especially for multiple platforms. But if someone does them and keeps them running, great.

Roadmap/docs: Sorry to say this, but I became very tired of everyone coming up with "upfront" demands. This project was developed by a handful of people in the last say 6-7 years for free, and even the README is seldom read. In my point of view, if someone wants to start, (s)he will (need to) find a way, f.e. by asking questions, exploring existing resources like source code, available docs and mailing list archives. It is the first stage of contribution.

We don't necessarily agree on the web area. Harbour already uses it for binary downloads for certain misc files which seldom if ever change. The existing release archive is the same thing. If the goal is to abandon sf.net, that is. Anyhow the release feature should be tested first, and if it can handle the problem properly, it's still an option.

Repo will most probably be tagged on next stable release (well, I hope), as it was tagged in all former releases. But those tags got lost on SVN -> Git conversion. Again: once the Git commit hashes for 3.0.0, 2.0.0, 1.0.1 and 1.0.0 are identified, they can be very easily added back anytime.

from core.

Bad news: Since SVN branches and tags were not imported to Git and the stable releases were marked in said branches/tags, the source snapshots made from them are lost from this repository, meaning it's not possible to tag them. Except for 2.0.0: 2252b2f

from core.

After reading the current final v3 Release API docs, it appears to cover all use cases that Harbour needs. Will need actual testing to decide if its a perfect fit.

from core.

The tool travis-ci uses for deploys has support for GitHub Releases.

See: https://github.com/travis-ci/dpl#github-releases

Harbour is already using travis-ci.

from core.

Yes, I implemented it for Harbour. The release thing is new since, thanks for the link. Looks useful, though it will only cover Ubuntu 64-bit binary builds [plus all my previous reservations apply].

from core.

Release API tested OK, but it's unusable directly from bash/batch scripts. It requires programming (Harbour scripts) or additional tools.

from core.

Releases are tied to Git tags. Git tags cannot be deleted, so daily release would mean a new tag every day. This isn't convenient and it's a no go for me for this purpose. Same problem with past releases: tied to tags. For future final and manual pre-releases it's very good though.

from core.

In the context of harbour, it's already available a nightly binary build for Windows only. Right ?

It's not possible for GitHub, without using releases, and it's not viable to have a new tag every day.

So, Releases and Tags area just usable in GitHub for final and future releases, like 3.2.0+.

For me it's a closing topic, fell free to close, as the initial goal of this issue was debated and defined, to my understanding.

About nightly binary builds, I think it's another issue, don't you ?

We could use better the travis-ci to give us more hints on branched pull requests before merging it to master ... ok, another topic! 😃

from core.

In the context of harbour, it's already available a nightly binary build for Windows only. Right ?

Right, but we've been talking about dropping sf.net, and the nightly uses that.

Nightly binaries are indeed a separate issue by itself. I personally prefer not to "invest" any more free time into them though.

We could use better the travis-ci to give us more hints on branched pull requests before merging it to master ... ok, another topic!

Elaborate on "more hints" (indeed another topic). Travis-CI is already used for verifying pull requests. Of course more validation could be added, f.e. the logic of bin/commin.hb, or else.

from core.

After some further research I learned that it is possible to delete a tag, so it appears theoretically possible to use the GitHub release system for daily/nightly builds.

from core.

You mean, a permanent nightly tag (and release), that would be removed and recreated every night with the current binary release (main platforms).

Sounds good enough to me!

from core.

Yes.

from core.