ipfs
Test version returned by go-ipfs during build process
In go-ipfs-0.4.3-rc1 we made a mistake of leaving version inside the go-ipfs itself on 0.4.3-dev.
This broke ipfs-update, we should be checking it as a part of build process.
I want to do this, but its a little difficult to do as we cant run every binary that we build, and the system has to be agnostic to what programs its building and distributing.
We could probably implement this as a sort of "pre-build" step.
Aside:
This is starting to feel like a gx thing... I think we should look more into how we can integrate a gx-bin idea with distributions.
- +1 to integrating with a gx-bin thing. Distributions website could be a thing gx-bin produces. (But this is likely a bit far off)
- also make the "default bin" something explicitly settable so that a dev build IS NOT treated as a release. Maybe can have another button for the next RC (to promote it).
- could lazy load that by using a whole distribution section for itself for now (like a go-ipfs-rc distribution) On Thu, Aug 4, 2016 at 11:31 Jeromy Johnson [email protected] wrote:
I want to do this, but its a little difficult to do as we cant run every binary that we build, and the system has to be agnostic to what programs its building and distributing.
We could probably implement this as a sort of "pre-build" step.
Aside: This is starting to feel like a gx thing... I think we should look more into how we can integrate a gx-bin idea with distributions.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ipfs/distributions/issues/71#issuecomment-237589908, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIcoS98bGdNX6mya4OmYRGaRRriF8lWks5qcgWzgaJpZM4JYicy .
The dev release problem can be easily resolved with semver, if release has a prerelease tag, it isn't new stable release. So we pick first newest version without prerelease tag and then we pick newest from all, if it is newer than the stable version, show it too.
No, it needs to be an explicit choice. We may make a full release and still opt to give people the last one because of found problems, etc.
The default version is explicitly set via the current file in each distribution. The reason we've had this issue is that my automation scripts for adding and building new versions currently overwrite that file with the new version we're adding. I should probably make an interactive prompt asking if we want to update the 'current' version.