Updating to 1.10


  • Admin

    So, Mojang recently released the first pre-release for Minecraft 1.10, which means that the full-release should not be too far away.

    Right now, a lot of major features from 1.8 to 1.9, and even some from 1.7, are still not implemented in Glowstone++. Thus, we need
    to decide how we want to proceed with the update to 1.10, since some server owners still want to stick to 1.9 and prefer having a
    complete version rather than a feature-incomplete 1.10 server.

    What I propose is to focus on 1.9 development on the main branch, and develop a 1.10 version in a separate branch. As such, we can
    focus on the development of features on the master branch, and when we feel we have reached a somewhat complete feature-set for
    earlier versions, we can merge the 1.10 branch into master and release G++ for 1.10. For example, I currently have a
    branch for 1.10 that I update as snapshots come out.

    What do you think?


  • Admin

    We really need to start utilising the milestone system. I think you’ve said that, but it’s worth reiterating.

    I would say that we should work on features starting from the version after the latest version we have parity with. If we haven’t completed 1.7 features, but we do have 1.6, then we need to focus only on 1.7, and then 1.8 after that, etc.

    That’s how I’d do it anyway.

    I guess we’d have to enforce it somehow - Maybe bountysourcing issues, prioritising the PRs for the version we want, or just not accepting PRs outside that scope at all? I’m not sure.


  • Admin

    Glowstone should stop being seen as tied to a Minecraft version. We are separate software, and we should act like it.

    We should look at version support, like supporting 1.10 as an additional feature instead of a target. I don’t see the point in artificially delaying a feature when it’s already finished. If protocol support for 1.10 is done, why not merge it into master?

    Branching Glowstone into different Minecraft versions with targets for all of the features in that version is unproductive. We don’t need to group features by version because each feature can be implemented independently of most other features introduced into a new Minecraft version.

    I feel like it is more useful to decide on what features are most important to us and the community, and how easy they are to implement, rather than following what version Mojang implemented a feature in.


  • Admin

    Supporting multiple versions (even if it was just one at a time) would certainly be a very neat feature. One that would set us apart from all of the craftbukkit forks/clones, in fact. However, I still think we should go back and move forward; Mojang implements Minecraft features on a rolling basis and we should do the same features in the same order in order to keep up with expectations.

    That doesn’t mean the protocol implementations can’t be separate, though.


  • Admin

    I don’t think that doing features in the same order is the expectation. We should see what features are the most wanted by a community vote or something like that and then contributors can better decide on what features to spend their time on. Of course, they shouldn’t be enforced to only do the top 5 features or so, because those may be hard to implement and a contributor might not have the time or the interest to do those features. Honestly, we need all the features we can get.

    Maybe a lot of people don’t think slime blocks are all that important, but they really want elytras. We shouldn’t do slime blocks first just because Mojang added that feature before they added elytras.

    Going off of the voting idea, maybe we should make a Google Form so people can vote on what features they want since not everyone can prioritize features through Bountysource.


  • Admin

    It’s not the entire expectation; the expectation is feature parity, and I feel like doing this by increasing version is a much easier way to keep people focused.


  • Admin

    What do we do with the “unfocused” contributions


  • Admin

    If we split things into milestones, we can just prioritise the current milestone. Maybe even have a branch for it? I’m not sure what your preferred method of organisation is.

    There’s nothing to say we can’t deal with the other stuff as well, but we should prioritise our… priorities…

    …you know what I mean.


  • Admin

    I don’t want a developer to feel discouraged about contributing the one feature they had time for that isn’t in the current milestone.

    And also, I don’t think we can even get many people to focus on a milestone. We have many volunteer contributors that aren’t part of a team like Sponge’s developers are. Most people who contribute to Glowstone find a feature they’re interested in, send a pull request and then disappear for months.


  • Admin

    Yeah, that’s the main problem as I see it. I wouldn’t say we don’t have a team, though. Don’t forget about all the people that are allowed to contribute directly and manage issues - the contributor group.

    But you’re right, this wouldn’t work without a handful of dedicated developers. I can only think of one or two people that would be interested in adhering to it right now.


  • Admin

    Well people in the contributor group aren’t necessarily dedicated developers. We add pretty much anyone who contributes a fair bit to Glowstone, regardless if they send in one fairly sized PR, or a bunch of small but helpful contributions frequently.


  • Admin

    Of course, but they’ve proven that they care about the project.


  • Admin

    They may care, but they may not be able to set aside time in their day to follow a schedule or release plan even if they really want to.

    I really still think that we should allow people to do whatever they want, but also help people find things to do. I think that we should have some lists of things people can do.

    There can be one list for relatively easy things so that new contributors can get started, a list that orders features by community votes, and one that organizes features by Minecraft version, so that contributors can easily decide what to work on.

    Eventually we will get feature parity, and it will take the same time really no matter which way we do it, but I think that by giving contributors that freedom to add whatever they want will make sure that some features get added as soon as possible.


  • Admin

    Well, do whatever you feel is best for this. But we definitely need to start using the milestone system. That would be the best way to compile these “lists”, I think.


  • Admin

    I really liked SpaceManiac’s milestone system, so I guess I will add that, just with a few tweaks to make it more manageable.


  • Admin

    I never actually saw that - How did it work?


  • Admin


  • Admin

    @mastercoms Yeah, that works. Now we need to just get some tickets set up.


  • Admin

    Just to mark the fact that 1.10 got released today. Spigot update is probably underway.


  • Admin

    @momothereal said in Updating to 1.10:

    Just to mark the fact that 1.10 got released today. Spigot update is probably underway.

    Jesus, already? What do we have to worry about with this one?


Log in to reply
 

Looks like your connection to Glowstone was lost, please wait while we try to reconnect.