VP
хотя ktor об этом не слышал 🌝
Ну я про сам котлин
Size: a a a
2020 May 07
QH
Ой ли. Тут 100500 случаев, когда «новый type inference ломает код»
или IDE 🌚
VP
Ой ли. Тут 100500 случаев, когда «новый type inference ломает код»
Так его не зарелизили. А вот зарелизят - посмотрим, что он сломает, и можно ли этот код назвать "нормальным".
VS
Ну я про сам котлин
type inference. good code marked red in idea и т.п.
VP
type inference. good code marked red in idea и т.п.
Так это хитрое действие для его обкатки же.
Плагин в идее может сломаться в любом патче, но это не слом совместимости - это рядовые баги, которые есть везде.
Плагин в идее может сломаться в любом патче, но это не слом совместимости - это рядовые баги, которые есть везде.
AM
или IDE 🌚
Продукты к семверу слабое отношение имеют всё же. А идея со своей calver к семверу вообще никакого отношения не имеет)
VS
Так это хитрое действие для его обкатки же.
Плагин в идее может сломаться в любом патче, но это не слом совместимости - это рядовые баги, которые есть везде.
Плагин в идее может сломаться в любом патче, но это не слом совместимости - это рядовые баги, которые есть везде.
Я ж говорю: у Kotlin проблема версий меньше. Там 1.0 уже было и всё норм.
А у serialization — версия 1.0 отсутствует. И это печально
А у serialization — версия 1.0 отсутствует. И это печально
VP
Я ж говорю: у Kotlin проблема версий меньше. Там 1.0 уже было и всё норм.
А у serialization — версия 1.0 отсутствует. И это печально
А у serialization — версия 1.0 отсутствует. И это печально
Это не печально для разработчиков, которые могут смело сломать ABI, не потеряв репутацию
VS
Это не печально для разработчиков, которые могут смело сломать ABI, не потеряв репутацию
Они могут смело ломать API/ABI, выпускать 1.2 или 2.0 и быть на коне с репутацией
EG
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0'
implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.2.0'
implementation 'androidx.activity:activity-ktx:1.1.0'
implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0'
implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.2.0'
implementation 'androidx.activity:activity-ktx:1.1.0'
EG
что в них?
VP
Продукты к семверу слабое отношение имеют всё же. А идея со своей calver к семверу вообще никакого отношения не имеет)
Без определения API модуля трудно вообще говорить про semver. Так-то IDEA умеет капитально ломать workflow в патче, но calver в этом не виноват.
AM
Без определения API модуля трудно вообще говорить про semver. Так-то IDEA умеет капитально ломать workflow в патче, но calver в этом не виноват.
Всё так
VP
Они могут смело ломать API/ABI, выпускать 1.2 или 2.0 и быть на коне с репутацией
Не могут, с этим жить тяжело, будет горение в сообществе.
Ломать всё в 1.2 - это очень плохо. Ktor позволил себе это, чтобы избежать утечек из-за неправильного использования, но это довольно опасный поворот.
Ломать всё в 2.0 надо осторожно, подготовив всех к этому, а в идеале - сменив пакет и artifactId. Иначе параллельное использование 1.x и 2.x превратится в пытку. А от библиотеки такого уровня будет очень много зависимых, и масштаб трагедии будет большим.
Ломать всё в 1.2 - это очень плохо. Ktor позволил себе это, чтобы избежать утечек из-за неправильного использования, но это довольно опасный поворот.
Ломать всё в 2.0 надо осторожно, подготовив всех к этому, а в идеале - сменив пакет и artifactId. Иначе параллельное использование 1.x и 2.x превратится в пытку. А от библиотеки такого уровня будет очень много зависимых, и масштаб трагедии будет большим.
VS
Не могут, с этим жить тяжело, будет горение в сообществе.
Ломать всё в 1.2 - это очень плохо. Ktor позволил себе это, чтобы избежать утечек из-за неправильного использования, но это довольно опасный поворот.
Ломать всё в 2.0 надо осторожно, подготовив всех к этому, а в идеале - сменив пакет и artifactId. Иначе параллельное использование 1.x и 2.x превратится в пытку. А от библиотеки такого уровня будет очень много зависимых, и масштаб трагедии будет большим.
Ломать всё в 1.2 - это очень плохо. Ktor позволил себе это, чтобы избежать утечек из-за неправильного использования, но это довольно опасный поворот.
Ломать всё в 2.0 надо осторожно, подготовив всех к этому, а в идеале - сменив пакет и artifactId. Иначе параллельное использование 1.x и 2.x превратится в пытку. А от библиотеки такого уровня будет очень много зависимых, и масштаб трагедии будет большим.
Т.е. типа сейчас они могут сломать всё подряд и не менять artifactId и т.п.?
Где логика-то?
Если хотят (или случайно) (или придётся) ломать, то не суть какая сейчас версия. 0.22 или 1.22.
Всё равно уже «есть пользовательская база, у которой 0.21, у которой 0.20 и т.п.»
Где логика-то?
Если хотят (или случайно) (или придётся) ломать, то не суть какая сейчас версия. 0.22 или 1.22.
Всё равно уже «есть пользовательская база, у которой 0.21, у которой 0.20 и т.п.»
VP
Т.е. типа сейчас они могут сломать всё подряд и не менять artifactId и т.п.?
Где логика-то?
Если хотят (или случайно) (или придётся) ломать, то не суть какая сейчас версия. 0.22 или 1.22.
Всё равно уже «есть пользовательская база, у которой 0.21, у которой 0.20 и т.п.»
Где логика-то?
Если хотят (или случайно) (или придётся) ломать, то не суть какая сейчас версия. 0.22 или 1.22.
Всё равно уже «есть пользовательская база, у которой 0.21, у которой 0.20 и т.п.»
Да, сейчас могут. Эта пользовательская база готова к тому, что что-то может сломаться. Мешать у себя в зависимостях эту библиотеку разных версий сейчас точно плохая идея.
Логика в том, что при выходе 1.0 разработчики заявляют, что всё стабильно и ломаться не будет (кроме исключительных случаев).
Логика в том, что при выходе 1.0 разработчики заявляют, что всё стабильно и ломаться не будет (кроме исключительных случаев).
VS
Да, сейчас могут. Эта пользовательская база готова к тому, что что-то может сломаться. Мешать у себя в зависимостях эту библиотеку разных версий сейчас точно плохая идея.
Логика в том, что при выходе 1.0 разработчики заявляют, что всё стабильно и ломаться не будет (кроме исключительных случаев).
Логика в том, что при выходе 1.0 разработчики заявляют, что всё стабильно и ломаться не будет (кроме исключительных случаев).
Про это и речь: с текущим подходом пользовательскую базу не наберёшь
VS
И они всё равно должны быть готовы, что после 1.0 будет 2.0
VP
Про это и речь: с текущим подходом пользовательскую базу не наберёшь
Тем не менее, она есть и даёт ценный фидбек
VP
Вот с ktor, например, всё немного иначе: на нём строится меньше библиотек и больше приложений.
ABI там ломали активно, но это почти никого не задевало. И после 1.0 такие действия не так страшны, потому что пользователи вряд ли столкнутся с конфликтом версий.
А вот несовместимость библиотеки сериализации - это большая беда, и я не думаю, что даже в 2.0 они решатся ломать что-то серьёзное. Пользователям будет очень больно, если она к этому времени заметно распространится.
ABI там ломали активно, но это почти никого не задевало. И после 1.0 такие действия не так страшны, потому что пользователи вряд ли столкнутся с конфликтом версий.
А вот несовместимость библиотеки сериализации - это большая беда, и я не думаю, что даже в 2.0 они решатся ломать что-то серьёзное. Пользователям будет очень больно, если она к этому времени заметно распространится.