WE DID IT! Thanks everyone who helped us crowdfund Loomio 1.0. We love our community! ×

Adopt a versioning scheme and release cycle.

Discussion

  • Sean Tilley created a proposal: Adopt a versioning scheme and release cycle.
    1 year ago
  • Jason Robinson agreed: Partly relating to this I created a proposal for a branching model which currently is missing. Definitely a release and versioning scheme is needed, although this proposal doesn't define what exactly it should be ;)
    1 year ago
  • Flaburgan agreed: For the moment, I think we just need to branches, "unstable", and "stable", which would be make with the unstable branch once a month (for example). This is linked to ¨Define a clear git branching model¨
    1 year ago
  • Definitely. I think between getting a stable/unstable branch and adopting a release cycle, we could also make packaging for distorts much easier.

    They all just kind of seem to fit together, and a short release cycle can help us better define short-term goals for the platform.

    Loading...
  • I’m not sure if we really should implement time restrictions, just use regular http://semver.org/ and bump version numbers if needed.

    Loading...
  • @Jonne: Thanks for the SemVer link, that’s extremely interesting. I think for the sake of packaging and creating dependencies, semantic versioning is a good idea.

    My thought on time restrictions: I think part of the problem is that because we haven’t had any sort of time restriction at all, it’s resulted in a wide-overreaching, somewhat vague roadmap, and the constant status of being “Alpha”. I think that by adopting, say, a six-month release cycle (or whatever increments necessary), we could make short-term roadmaps for features, fixes, and improvements, planning accordingly for the chunk of time we give ourselves to hit release. If we have six months to get to a release, then we plan features that can be accomplished and made release-worthy within that span of time.

    Granted, roadmap items would probably be smaller, but they’d also be things that we could realistically get done for a given amount of time. Furthermore, if you look at a lot of user-oriented FOSS projects (Gnome, KDE, Unity, Firefox, LibreOffice), many of these types of projects have a time-based release cycle. I believe having that encourages developers to get more done together, and can aid the collaborative process.

    Partially related, we could also tag stable releases in our GitHub repo when we approach release time, pointing out to podmins, developers, and enthusiasts that the release is considered stable, or at the very least, having a green build and being stable enough to run a production environment.

    Loading...
  • We can’t compare to the big FOSS projects. Yet. For Diaspora I still see the possibility that no feature/change justifying a major or minor release is done in that time. On the other hand it might be done shortly after the timed release and then we can’t easily do API breaking changes because podmins might want to deploy this new feature and others want to wait for the next release.

    That said I still vote for just doing SemVer, defining our “API” to not only being a potential client API and our federation protocol but also our frontend. Massive changes there should justify at least a new minor release too.

    Loading...
  • Jonne Haß created a proposal: Adopt semantic versioning with no time constraints
    1 year ago
  • I created a new proposal since only two people (had time to) vote on the old one.

    Loading...
  • I’d really like to see some sort of time-related release cycles. we don’t have to enforce it strictly (if something justifies a release, we should just go with it) and it doesn’t have to be all that precise (e.g a base-cycle of 6-8 weeks, with a buffer of +-2 weeks or whatever would be enough).
    But I don’t really like the ‘no deadlines’ structure … it’s hard for me to get work done without a goal ;)

    Loading...
  • Can’t “Oh yeah, if I finish that I can release a new version!” be a goal? :P

    Loading...
  • ;)
    I don’t know about you, but as a student most of my motivation comes from approaching deadlines.

    Loading...
  • Okay I can see the motivational aspect but that’s the only benefit I see, the downsides don’t out weight that IMO: We would need to decide what to include, estimate if it can be done that time frame (impossible in a project where everybody can join and leave anytime) and lots and lots of bad karma for missing to include stuff while having it announced/stated or postponing a release yet again and again. Remember podmins certainly will plan downtimes for announced releases, that really gives bad karma if we miss it :)

    Loading...
  • Ok I see your point, and I think the downsides outweigh my personal motivation issue :P

    Loading...
  • Jonne Haß agreed.
    1 year ago
  • Florian Staudacher agreed: ok, so that would be MAYOR.MINOR.PATCH
    1 year ago
  • RELEASE(or whatever we could call it).MAJOR.MINOR.PATCH actually according to my proposal.

    Loading...
  • Sean Tilley agreed: I like it. Will we adopt a roadmap for milestones to hit for stable release? (in terms of platform and feature development?)
    1 year ago
  • I think we should just try it with Githubs milestone feature instead of a roadmap.

    Loading...
  • Seems simple enough; to be fair we haven’t really used it all that much before, but seeing as it’s already there anyway… ;)

    Loading...
  • Oh, just one thing I forgot in the proposal, but I think we all agree about: A changelog should be included into the repository.

    Loading...
  • Jason Robinson agreed: I totally agree and this would be nice to be implemented at the same time as we improve the branching model
    1 year ago
  • Yep, that’s why I did another proposal just now, so we can init the branching model and release a 0.0.1.0 the first time we got something stable in the develop branch.

    Loading...
  • groovehunter agreed.
    1 year ago
  • SemVer scheme +1 of course.
    Timing: What about a time raster. IF there is a new release, release it at beginning of the month. (quarterly is to much I guess).
    You have the idea of the two advantages - dependecies + admins ? I could elaborate.

    just btw for the ruby gems releases this would be very useful (as guideline!)

    Loading...
  • Hm, pushing non hotfix releases on something like every second sunday could be an option to thing about. I’ve to think about it a bit more.

    Loading...
  • Steven Hancock agreed: I agree with semantic versioning. People should have a way, before they upgrade the software, to know if there are any breaking changes.
    1 year ago
  • Tom Scott agreed: I use SemVer for every one of my projects. It's also how I built the tagger, so I assumed we'd be using it.. :)
    1 year ago
  • Billy O'Connor agreed.
    1 year ago
  • movilla agreed: It's a great idea that will help developers, users, and even podmins bloggers who publish news about new versions.
    1 year ago
  • Dave Yingling agreed.
    1 year ago
  • Yay! We have a versioning scheme :)

    Loading...
  • And https://github.com/diaspora/diaspora/pull/3589 gonna already shout it out via a custom header :P

    Loading...
  • Excellent. Should we consider a v 0.1 stable release soon, or should we clearly detail out some milestones we should hit to get there? (Anything to get away from the Alpha/Beta scheme)

    Loading...
  • Nobody actually read that proposal :P
    First version would be 0.0.1.0 (release.major.minor.bugfix). And I’m aiming for the first release pretty soon once my new configuration system has proven stable enough. From that on I’ve my personal list of things to do but I won’t assign that milestones, one of the benefits of SemVer is IMO that not you tell what a new version is but the changes you make. So lets just see what happens, releasing new versions as needed ;)

    Loading...
  • My bad, sorry Jonne. What I meant specifically was that I was wondering what we need to do still so that we can start officially making stable releases. IMO, it’d be useful for anyone trying to package Diaspora for different distributions.

    Loading...
  • Have just seen the announcement on the mailing list of the first ‘new’ release. It all looks fantastic, and gives me real hope for the future. Thank you so much, Jonne, and everyone else involved in this initiative.

    Loading...
  • I guess the release cycle stuff is kind of open still. How we decide when to release, etc. I’m kind of thinking a monthly release cycle would be cool - just push out whatever is ready (by using a release branch of course) and bump the semver according to what kind of changes are included.

    How do others feel about the releases? Personally I would like to see releases quite often, maybe monthly would be nice - not too fast but not too slow?

    Loading...
  • I think we’re just doing SemVer-driven versioning and releases for the forseeable future, in which the version is bumped by the amount of actual changes and the relative scope of how much code is being changed. It’s not so much that it’s time-driven, so much that the code moves along and is updated automatically.

    The real question is, at what level do we consider our code stable enough for release? What criteria would we need to ensure that the release build is green, that sweeping changes are documented? Finally, what strategies can we better adopt for getting the word out on releases?

    Loading...
  • I think we (or rather, the devs) will have to play it by ear a bit to start with, until there is a good pool of devs and work is rolling. A fixed release cycle with frequent updates might put too much pressure on the few core devs we have at the moment. (I think it’s only a few still, in any case.)

    So I think for the time being, it would be better to have a release when there is something ready to be released and worth of a release update, rather than on an fixed time scale. The main thing is 1) to keep things moving, so that we don’t again hit a patch in which nothing is (apparently) happening with D* development, and 2) not to promise anything which then isn’t delivered. As long as things are happening, even if there is no new release for a while because the devs are hard at work on a major structural change which is taking a long time (for example), there doesn’t need to be a release every few weeks, in my opinion. This is where Sean and others can help things along with regular and open communication about what is happening behind the scenes. I say open, because for a time the communication we did get with the core team was opaque, and that compounded the problems the D* community was experiencing.

    All this is said as a non-dev, so might be completely wrong. I guess it is for Jonne and the other core devs to decide amongst themselves what is the best release scheme.

    The questions in Sean’s second paragraph are worth asking, and one reason I’d be wary of a fixed-time release cycle would be the possibility of rushing something out before it has been fully tested, in order to meet the deadline. If communication about progress is frequent and open, I don’t think new code needs to be released so frequently.

    (I assume preparing a release and release notes also takes dev time, so it might be good to wait until there is a significant change in the code before releasing for this reason as well.)

    Apologies if any of this is off-beam; as I say, unfortunately I know next to nothing about coding and so can’t help with this.

    Loading...
  • Blimey that was a long post. Sorry. Without being able to preview, and because the input box remains small so text disappears upwards, I seem to end up writing far more than I realised, and then not being able to edit it down.

    Loading...
  • since we successfully adopted the versioning scheme (whis is what the headline says), I’d say everything else could go into a new discussion? or how do we wanna handle it? (just hijack the thread or start a new one?)

    Loading...
  • The topic is “ Adopt a versioning scheme and release cycle” so seems right to me? :) A discussion is different from a proposal, there is no reason we cannot discuss here and have more proposals relating to the subject. Adding extra discussions will just fragment the discussion imho.

    Loading...
  • Just a thought: now there’s a proper versioning scheme and we’ve had our first proper release, is it time to remove the alpha symbol from the top left of the menu bar? Not sure whether this is all pods or just jd.com.

    I realise it’s still early days, and it’s useful when people are moaning about not everything working perfectly to say that it’s still alpha software and not a full production release, but thought I’d mention it for those of you involved in development to decide on.

    Loading...
  • Yeah, I’d definitely say so. Nice catch, Goob!

    Loading...
  • Good man. Visible progress!

    Loading...
  • It might be handy in the long run to display a version number on pods, just for the sake of making bug reporting easier.

    Loading...
  • The whole right panel thing needs cleanup and imho redesign - maybe the version number could be there as the last item - would be cool to show it for sure.

    Loading...
  • I think there is some misunderstanding on what is a major, minor and patch.

    AFAIK in SemVer this is, for X.Y.Z:
    X = major
    Y = minor
    Z = patch

    This is pretty much universal in the software world. Do we agree to follow this standard? Currently Diaspora* is running the first patch and personally I would like minor changes to increment a minor version, not just a patch.

    Loading...

Current decision

Previous decisions

  • Adopt semantic versioning with no time constraints

    Closed
    Closed 1 year ago
    Proposed by Jonne Haß 1 year ago

    See http://semver.org/.

    With the following changes:

    In our case API is defined as:
    - Our frontend (major changes -> major version, minor changes -> minor version, you’ll get the idea).
    - The federation protocol.
    - The client API (not existent yet)

    Big internal and structural changes that do not influence the users of all sort (users, client developers, pods), except perhaps for performance, still only justify a minor version.

    The version is prefixed with another number which will be increased at community decision instead of a major release. This is to avoid a false sense of rapid development and increasing stability while still maintaining a meaning in the version number changes from the start.

    The first version to release will be 0.0.1

    38% of members stated their position (10/26)

    Positions

    Florian Staudacher ok, so that would be MAYOR.MINOR.PATCH
    Sean Tilley I like it. Will we adopt a roadmap for milestones to hit for stable release? (in terms of platform and feature development?)
    Jason Robinson I totally agree and this would be nice to be implemented at the same time as we improve the branching model
    Steven Hancock I agree with semantic versioning. People should have a way, before they upgrade the software, to know if there are any breaking changes.
    Tom Scott I use SemVer for every one of my projects. It's also how I built the tagger, so I assumed we'd be using it.. :)
    movilla It's a great idea that will help developers, users, and even podmins bloggers who publish news about new versions.
    [Show members who have not yet decided]