Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)
  • From: GIREESH PUNATHIL <gpunathi@xxxxxxxxxx>
  • Date: Thu, 23 Jan 2025 11:49:11 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=in.ibm.com; dmarc=pass action=none header.from=in.ibm.com; dkim=pass header.d=in.ibm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UsGUZN8AR3p0JiIIkxBaqZrDsGtmBlQ6kbfdqFqfkeo=; b=IaqMch2wjfFVzCbfrjolG6yWTXP7LCyUV37zr0Typ+LO5li8aeNBroq67r/oj3SarYlThsO3/0/YMn82P/lNwDiQmPv1BWjF6CmocPqz1cxqJNRluIQcGa5s0VD/ufnuc2OQgxzVsCT53QyzoZS4/rf5gTHSTFVgAGmahyKVcVzl5QGnZZ4w7GFj1mKHsCxc0QnnU4DjxCgtL5JygubJGPmmcAxMIT5+kR7OS1dTnyJ3qpoaUY4Ht1MhtXXoFaIffMgJPS6/mCkOwdQbrT3CJw+jUtPmZv2UVqmvN+V+07RDIQZVfYQcfCqsk1rxZFSsMqJ/sK+/w+4RpgZPfR1OfA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CiUsGfyN6Ipr2pCIAhysKiWzXCNiYTJKu/NTd08I9++uK1xP98K6Yyo++RzIRkwKAXaPnzP3jXP8CAiJnV2nTd8fs3vMrb546uiXzTXyRYUYdxFQwUKmsgUKMubMFVIbVEyiXUrRF/aYWaSWBvpHkaUkhsPuOMEZvpml4BFgMXX/gJKsBfhxjEwGB2rQiy+H9eEerqf7JYBuq/bLTKyawwM3JRuM+uUzlhmtqML8kgW8ZHjcnHXQcifiJyHAc+NLH3EP9j0P2AXcU7sfP81Yr2JBLeosiitMLGK0S30+RddCpNYiJzIc6X442dl4Gw7nE8yNeLIxOUY7iVVjppFYAw==
  • Delivered-to: jdt-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/jdt-dev/>
  • List-help: <mailto:jdt-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jdt-dev>, <mailto:jdt-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jdt-dev>, <mailto:jdt-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHbZTL335CAtZkXiEeJrK+7ClOTJrMUV3oAgADad4CAAKCUgIABhZqAgAAy7gCAAfkngIABUhWAgAGqZwCAAIY7AIAAIJsAgAG6+oCAAJAWgIAAA30AgAAQNwCAAB2fgIADN+EAgAAqCACAAAN7gIAAF/4AgAEtmfA=
  • Thread-topic: [EXTERNAL] Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)

this is a great conversation, thank you all for sharing your experiences as maintainers. I have been closely following the discussion, learning a lot, and exploring examples from the open-source world.

 

I see prior arts for both models:

- preview features in master branch: vscode, react, angular, rust...

- preview features in beta branch: k8s, tensorflow, node.js...

 

and the overarching trade-off seem to be:

- easy branch management (main) vs. greater isolation (beta)

- easy for testing (main) vs. less risk of code leak (beta)

 

which leads to a more generic selection criteria:

- main: matured projects with frequent releases

- beta: growing projects with heavy experimental research

 

I look forward to learning more from this discussion and how these principles apply to JDT's (unique?) context!

 

thanks, gireesh

 

From: jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> on behalf of Stephan Herrmann via jdt-dev <jdt-dev@xxxxxxxxxxx>
Date: Wednesday, 22 January 2025 at 11:18 PM
To: Mickael Istria <mistria@xxxxxxxxxx>
Cc: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>, Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jdt-dev] About Y-Builds (was Re: 4.35 Y-Build: Y20250111-1000 - BUILD FAILED)

I don't believe this is a hugely relevant scenario to begin with, and I don't think you understood the complexity of supporting several preview versions in one implementation. I was tempted to ask you to prepare a PR for what you think to be

I don't believe this is a hugely relevant scenario to begin with, and I don't think you understood the complexity of supporting several preview versions in one implementation.

I was tempted to ask you to prepare a PR for what you think to be easy, but I'm not sure who would review it.

 

I'll focus on issues where I know that they're relevant and that I can fix them. I won't continue in this particular discussion.

 

On 22.01.25 17:22, Mickael Istria wrote:

You're only looking at the trivial part, but you miss the tons of locations that query this data. With your proposal we would never be able to remove any preview checks of features that have long matured, and we would even need separate checks for repeated previews with changes between them.

am I missing anything?

 

I found JavaFeature.isPreview() has 2 consumers:

* ProblemReporter.validateJavaFeatureSupport(...)

* ProblemReporter.validateRestrictedKeywords(...)

 

both do take can access the compliance from `this.option.sourceLevel`.

So it would be possible to replace each call to `isPreview()` by some `isPreview(this.options.sourceLevel)` which would instead of directly returning true/false, would look like

```

enum JavaFeature {

   ...

   int lastPreviewVersion; // set to 0 if was never preview

   boolean isPreview(long compliance) {

      return compliance <= lastPreviewVersion

   }

```


--

Mickael Istria

Eclipse IDE developer, for Red Hat

Back to the top