Java 18.3
miniJUGJava переходит на 6-месячный релизный цикл и меняет схему версионирования.
Java всегда была известна медленным темпом выхода новых версий. В среднем новые релизы Java выходили приблизительно раз в 3 года: Java 7 вышла в 2011 году, Java 8 - в 2014, Java 9 - в 2017. При этом релизы были очень крупными, например в Java 9 вошло аж 99 JEP'ов. Постепенно Oracle понял, что в современном мире такой медленный темп выхода может навредить развитию и продвижению Java, поэтому принял решение перейти к 6-месячному релизному циклу. Таким образом, выход новых фич, которые могут быть выпущены прямо сейчас, не будет задерживаться из-за других более долгих фич. Например, Local-Variable Type Inference (var) возможно уже появится в следующей версии Java, которая выйдет в марте 2018 года.
Вместе с изменением частоты выхода релизов Oracle также планирует изменить схему версионирования. Будущие версии Java предлагается нумеровать в соответствии с годом и месяцом выпуска: Java 18.3 будет означать март 2018, Java 18.9 - сентябрь 2018 и т.д. Мотивацию по поводу перехода к такой схеме объяснил в своём письме Mark Reinhold (главный архитектор Java платформы).
Однако сообщество восприняло изменение схемы версионирования неоднозначно. На письмо Марка было множество ответов, где многие пытались переубедить Марка не менять схему и продолжать версионировать по-старому (10, 11, 12 и т.д.).
Противники новой схемы приводили множество аргументов. Попробуем резюмировать наиболее значимые из них.
1. Java только что уже поменяла схему версионирования (JEP-223), зачем её менять ещё раз? Получается, что JEP-223 ввели и сразу же выбрасывают на свалку ради более сомнительной схемы, что в будущем будет источником заблуждений и непониманий со стороны пользователей. Зачем менять то, что уже работает и работает хорошо?
2. Схема YY.MM выглядит как семантическое версионирование, но таковым не является, и это будет сбивать с толку людей. YY.MM внешне выглядит как MAJOR.MINOR, но в схеме MAJOR.MINOR вторая часть (MINOR) может измениться только, если происходят обратно-совместимые изменения. Однако переход от 18.3 к 18.9 является крупным релизом, в котором могут быть и обратно-несовместимые изменения (например, удаление deprecated API). Кроме того, при схеме YY.MM многим может показаться, что переход от 18.9 к 19.3 является более значимым, чем от 18.3 к 18.9, однако это не так. 18.9 - такой же полноценный крупный релиз, как и 19.3.
3. Для многих людей такая схема незнакома. Непосвящённые люди будут задаваться вопросом, что означает 18.3 и почему, например, нет 18.0, 18.1 и 18.2. И почему после 18.3 произошёл скачок сразу на 18.9.
4. Новая схема не позволяет по версии релиза понять, является он LTS или не-LTS. LTS означает релиз с долгосрочной поддержкой, и теперь после значительно увеличения частоты релизов не все из них будут LTS, как это было раньше. Впрочем, старая схема также не позволяет понять, является ли релиз LTS.
Подводя итог, можно смело сказать, что на текущий момент нет чёткого обоснования необходимости перехода на новую сомнительную схему. Перечисленные Марком преимущества этой схемы не кажутся достаточно вескими, чтобы заморачиваться с переходом. А зная тот факт, насколько неохотно вводятся изменения в Java платформу, необходимость которых не доказана, кажется несколько странным, что Oracle принимает подобные сомнительные решения.